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 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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
