ada(4) and ahci(4) quirk printing

Tue Apr 23 12:15:07 UTC 2013

On Tue, Apr 23, 2013 at 01:55:15PM +0300, Alexander Motin wrote:
> 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):
> >>>>>
> >>>>>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 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 not of the opinion that device quirks are debugging features,
especially considering the whole 4096-byte sector ordeal with SSDs.  Who
knows how many vendors won't add the hardware sector size field in ATA
IDENTIFY to their device?  :/

> >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?

Depends on the kind of VM.  The ones I've used (VMware Workstation,
VirtualBox, and KQemu) emulate some hardware -- usually for storage,
using a PIIX4 with classic IDE, or sometimes SCSI.  I've yet to see one
which offers AHCI or native SATA.

A HV (hypervisor) like Xen with HVM I think could do this, but that
would mean quite literally turning my only FreeBSD box into such a
thing, and I'm just not familiar enough with the technology to
accomplish that.

I guess alternately I could temporarily rent a box somewhere that uses a
HV with SATA disks, but the last time I tried to find such a provider, I
found many but none supported for FreeBSD -- only Linux.  (I did find
one, but their claim turned out to be questionable, as once I tried it
the system would never boot/install, and they refused to provide
something like a remote KVM so I could see what was going on on the
console).

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |