From owner-freebsd-stable@FreeBSD.ORG Tue Apr 23 11:01:24 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 695D4872; Tue, 23 Apr 2013 11:01:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id CBCF21718; Tue, 23 Apr 2013 11:01:23 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id b15so194675eae.2 for ; Tue, 23 Apr 2013 04:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bZ15rHIlT+YOUpmkggr42fuMmjz/IPxv5UEWWuHIA0o=; b=NK+nMb1QbUfpESMPIhTwkv/ScYL+9wQGc8OiMyft13w1Vuyh5X7VKJvs5yFPtTLgNg jTq3YxsLXI28grz9UUc13vPc84QMywxFMV1hwCOPC/g5DsOkHseacM0L9jU8N1cPKqPx 0VpLtqKQ/Hj6CW6LYBujj85AthnAbgJqMfIB0/mQkB/oa6svX9Drvdjgq4MffnKiqu1R 1+Bocau7TTOStxkoMxfKyqjWhwF5MVySGWPqPjBoTyyMPVJQQwMkPPdQUSrQPCicBNR5 RFA1H/7hcHCUmd1T1rYGAK1WRg/Uv3OMzJFcIWFPhBKArZ9PT8tWM3vGa578l/k7Laxm dwMg== X-Received: by 10.14.194.70 with SMTP id l46mr3331111een.28.1366714494623; Tue, 23 Apr 2013 03:54:54 -0700 (PDT) Received: from pc.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id s47sm46123998eeg.8.2013.04.23.03.54.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Apr 2013 03:54:53 -0700 (PDT) Sender: Alexander Motin Message-ID: <51766893.3030704@FreeBSD.org> Date: Tue, 23 Apr 2013 13:55:15 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130407 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: ada(4) and ahci(4) quirk printing References: <20130422051452.GA2148@icarus.home.lan> <51763BF9.2000506@FreeBSD.org> <20130423092602.GA58831@icarus.home.lan> <51765466.4040209@FreeBSD.org> <20130423104938.GA60586@icarus.home.lan> In-Reply-To: <20130423104938.GA60586@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kenneth Merry , freebsd-stable@freebsd.org 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 11:01:24 -0000 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