From owner-freebsd-stable@FreeBSD.ORG Tue Apr 23 12:15:07 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 399EB6E4 for ; Tue, 23 Apr 2013 12:15:07 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7141E64 for ; Tue, 23 Apr 2013 12:15:07 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta01.emeryville.ca.mail.comcast.net with comcast id TPo71l0031bwxycA1QF7al; Tue, 23 Apr 2013 12:15:07 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id TQF61l0091t3BNj8eQF6zU; Tue, 23 Apr 2013 12:15:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2F7D873A33; Tue, 23 Apr 2013 05:15:06 -0700 (PDT) Date: Tue, 23 Apr 2013 05:15:06 -0700 From: Jeremy Chadwick To: Alexander Motin Subject: Re: ada(4) and ahci(4) quirk printing Message-ID: <20130423121506.GA62232@icarus.home.lan> References: <20130422051452.GA2148@icarus.home.lan> <51763BF9.2000506@FreeBSD.org> <20130423092602.GA58831@icarus.home.lan> <51765466.4040209@FreeBSD.org> <20130423104938.GA60586@icarus.home.lan> <51766893.3030704@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51766893.3030704@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366719307; bh=xxSN4C731phkASTnsZn0x0yLCBwI/EjA524dUxDZAQI=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=kxou+EnGrZmiPvkQvRtna5R96eAe2NgWfCm4bpWiLzhgko/8EO6vIAl+P0rWCM6ul wIBWyqxINry7e5Bg5f7z0zxM36hROLE9Z6h008b99XcUIghNjG3F02Iav3oc8xQkP7 NsDqbUG1LEp6h1VdHHSTB/ILwCR2q1e+yX9GW+qD4E5XUeA5awvx8hSWH/r5UHyzgr /PuosDCHqc6bSTLZ69pISHtV1PSt4GawueEKrGZzxExUtzMszkuN3zQAtV/A3jJ4gO AT2ZxQCVwhdlmnUCxiKu5zq2AZ4Gop5IK4T6fpbgdfT7k5htw7yE+it+VQAybMlqNP AQfbNZ5wMCs/Q== Cc: freebsd-stable@freebsd.org, Kenneth Merry X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 12:15:07 -0000 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@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |