ada(4) and ahci(4) quirk printing

Jeremy Chadwick jdc at
Tue Apr 23 10:49:39 UTC 2013

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):
> >>>
> >>>
> >>>
> >>>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,
> >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.: 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 at |
| UNIX Systems Administrator       |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

More information about the freebsd-stable mailing list