Date: Tue, 23 Apr 2013 03:49:38 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Alexander Motin <mav@FreeBSD.org> Cc: Kenneth Merry <ken@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: ada(4) and ahci(4) quirk printing Message-ID: <20130423104938.GA60586@icarus.home.lan> In-Reply-To: <51765466.4040209@FreeBSD.org> References: <20130422051452.GA2148@icarus.home.lan> <51763BF9.2000506@FreeBSD.org> <20130423092602.GA58831@icarus.home.lan> <51765466.4040209@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 23, 2013 at 12:29:10PM +0300, Alexander Motin wrote: > On 23.04.2013 12:26, Jeremy Chadwick wrote: > >On Tue, Apr 23, 2013 at 10:44:57AM +0300, Alexander Motin wrote: > >>On 22.04.2013 08:14, Jeremy Chadwick wrote: > >>>I've written the following patches and done the following testing (see > >>>the results.*.txt files): > >>> > >>>http://jdc.koitsu.org/freebsd/quirk_printing/ > >>> > >>>Important: these are against stable/9 r249715. > >>> > >>>Folks are welcome to try these; I've tested about as best as I can. > >>> > >>>Questions/comments for Alexander and Kenneth: > >>> > >>>1. I'm not sure if the location of where I added the printf() code is > >>>correct or not, > >> > >>It seems fine for me. > >> > >>>2. Not sure if loader.conf(5) forced-quirks would show up here or not, > >> > >>As I see, they will. > >> > >>>3. It would be nice to have the same for SCSI da(4). I took a stab at > >>>this but the printing code I wrote never got called (or the quirks entry > >>>I added wasn't right, not sure which), > >>> > >>>4. I strongly believe quirk printing should be shown *without* verbose > >>>booting. I say this because I noticed some of the CAPAB printf()s only > >>>get shown if bootverbose is true. In fact, it's what prompted me to > >>>open PR 178040 ("My Intel 320 and 510-series SSDs don't show 4K quirks, > >>>yet advertise 512 logical and physical in IDENTIFY?! PR time!"). > >> > >>Let me disagree. bootverbose keeps dmesg readable for average user, > >>while quirks are specific driver workarounds and their names may > >>confuse more then really help. If every driver print its quirks, > >>dmesg would be two times bigger. There is bootverbose for it. > > > >I'm willing to bend on this assuming that userland has a way to display > >the quirks. I've already had one user contact me off-list stating that > >displaying of quirks is useful to them, but *without* bootverbose > >(because bootverbose shows too much information for them to have to sift > >through). And display of quirks (or in this case) was what prompted me > >to create PR 178040, since I had just *assumed* FreeBSD had 4K quirks in > >place for both models of SSDs. > > > >I think sysctl would be an ideal place for this. Is it possible to > >export active device quirks to sysctl (say kern.cam.ada.X.quirks), > >read-only, and preferably as a string (same printf() style used)? Or > >does that introduce complexities? > > > >If we can't reach an agreement, I'm happy to wrap the relevant bits with > >an "if (bootverbose)", but I really feel users should have some way to > >see this information outside of bootverbose. > > Both da and ada drivers already have sysctl's. It should be trivial > to add one more, especially if just numeric. I was hoping for an ASCII string, specifically something like what's outputted in my patches, i.e.: kern.cam.ada.2.quirks: 0x1<4K> And ideally it'd be nice to have the same thing for ahci(4), which right now doesn't appear to have anything other than the dev.ahci.X.%xxx tree stuff (which I think is handled by the device registration stuff, not the ahci driver natively). I'll worry about that later. The problem with just leaving it as a numeric is that it doesn't provide the user with any idea of what the value represents. They're forced to go through the source code + decode the numeric into it's bit values and figure out what's what. I'm pretty sure I can work this into sys/cam/ata/ata_da.c (looking at read_ahead as an example, though using SYSCTL_PROC not SYSCTL_INT, and for how SYSCTL_PROC works with this type of thing, referring to machdep.c for an example), but it'd be my first time doing any of this. I'll give it a shot. I really need to get myself a SFF PC for FreeBSD just for testing these types of things, unless FreeBSD has some magical way to "test a kernel" on a live system without having to reboot. (Sounds like black magic to me ;-) ) -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130423104938.GA60586>