ada(4) and ahci(4) quirk printing

Alexander Motin mav at
Tue Apr 23 11:01:24 UTC 2013

On 23.04.2013 13:49, Jeremy Chadwick wrote:
> 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 haven't told that it is impossible. I would just prefer to not 
complicate the code too much with rarely used debugging features.

> 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 ;-) )

Virtual machine?

Alexander Motin

More information about the freebsd-stable mailing list