From owner-freebsd-stable@FreeBSD.ORG Sun Nov 25 02:10:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16089B01; Sun, 25 Nov 2012 02:10:04 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0396D8FC08; Sun, 25 Nov 2012 02:10:02 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a14so3055144eaa.13 for ; Sat, 24 Nov 2012 18:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/qVU8hAc7kOEshgZjWd1NVxK7n6Z9GNGdPFGwPkcghM=; b=OkKe/+WUr96eq/ohdQHBmUsPk3OO3y4Cj4ZM81IgCX6muGa2f4fMYd/h0JwMO4NTYV mg0jdA/nvzv1aVG0hZrybKpJYZnu+UoDCzP7SX46w3wVcEdfOpISjYuxaPsBSK/WwMy2 SMY8b2+4ME6FauGEvR5htQiAhW0kFTNSXkOr7spW+wolG7s0E2OI6aMl6ebxeDMJYNTn XnpInXtJIIHpgqDbvvbD83aUaG9X1YFSoxYOI/GEYDdRYvkMe5rGmZ11bgJgRU9gzTP8 xZVkri8lkCG73GgFOsUSKD/l7UtaDLZ6x3Fg3MQTSLFYG/ehyDZCmGFV7h33Whwj/pvc dx7g== MIME-Version: 1.0 Received: by 10.14.184.134 with SMTP id s6mr29544076eem.43.1353809401680; Sat, 24 Nov 2012 18:10:01 -0800 (PST) Received: by 10.223.71.199 with HTTP; Sat, 24 Nov 2012 18:10:01 -0800 (PST) In-Reply-To: <20121123150719.M21191@sola.nimnet.asn.au> References: <50AD0E82.3070706@digiware.nl> <20121121194142.8c4bf7d1977f13801a021ccc@getmail.no> <20121122144400.M21191@sola.nimnet.asn.au> <20121122213328.J21191@sola.nimnet.asn.au> <50AE36FF.7080106@FreeBSD.org> <20121122224906.GE88593@in-addr.com> <20121123150719.M21191@sola.nimnet.asn.au> Date: Sat, 24 Nov 2012 18:10:01 -0800 Message-ID: Subject: Re: Increasing the DMESG buffer.... From: Kevin Oberman To: Ian Smith Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , freebsd-stable@freebsd.org, Alexander Motin , Andriy Gapon , Ronald Klop 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: Sun, 25 Nov 2012 02:10:04 -0000 On Thu, Nov 22, 2012 at 8:50 PM, Ian Smith wrote: > On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: > > On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer wrote: > > > On Thu, Nov 22, 2012 at 02:14:59PM -0800, Kevin Oberman wrote: > > >> On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd wrote: > > >> > On 22 November 2012 06:30, Alexander Motin wrote: > > >> > > > >> >> Neither ICH, nor any other driver I know have amount of information > > >> >> comparable to what HDA hardware provides. So the analogy is not good. > > >> >> Respecting that most CODECs have no published datasheets, that information > > >> >> is the only input for debugging. > > >> >> > > >> >> snd_hda also uses hw.snd.verbose=3. But it is used for even deeper driver > > >> >> debugging. It also enables a lot of debugging in sound(4), that can be too > > >> >> verbose for HDA debugging. > > >> >> > > >> >> I will recheck again how can it be reorganized, but I think that the real > > >> >> problem is not in HDA. We need some way to structure and filter the output. > > >> > > > >> > I honestly would like to just see it spat out using a userland tool, > > >> > rather than having the kernel print that level of topology data out. > > >> > > > >> > It's highly unlikely that a topology problem is going to cause a > > >> > system to not boot, right? So the kernel itself doesn't need to be > > >> > able to spit that data out. > > >> > > >> Maybe I'm missing something, but the data needed to adjust HDAC is > > >> available from 'sysctl dev.hdaa'. I have not looked at the verbose > > >> output in quite a while, but I think it is mstly or entirely hte > > >> information in that and 'sysctl dev.hdac'. I never needed to look > > >> elsewhere to get mine set up properly. > > Kevin, could you check http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works > - the ~85k example I used - against what the sysctl presents on yours? > > With the caveat that I don't have a snd_hda, I suspect the initial > information from hdacc0 and hdaa0 up to before "DUMPING HDA NODES" is > likely useful in verbose boot, assuming all of the nid info is available > by sysctl? Also the pcm0 and pcm1 data might be limited to that without > "DUMPING PCM Playback/Record Channels", "DUMPING Playback/Record Paths" > and "DUMPING Volume Controls", leaving in the mixer info as traditional > - again assuming that sysctl access covers it? Clearly basic discovery > of the particular wiring, routing etc should remain in verbose dmesg. > > > >> Also, isn't the entire verbose boot captured in /var/run/dmesg? > > > > > > Only if the message buffer hasn't overflowed before the utility runs to > > > populate the file > > > > Ouch! I did miss hte obvious. Thanks for pointing this out. > > I've noticed quite a few truncated verbose dmesgs posted over the last > couple of years, sometimes frustratingly starting after important stuff > like the CPU info or ACPI tables etc .. Lars presumably had increased > his buffer size to capture 85k, which would be well less than Adrian's > suggested 64k with more minimal hda + pcm logging. Perhaps a debug.snd. > or something tunable could reenable the higher verbosity if/when needed? > > > So we need to either expand the default buffer (not something I would > > want to do) or trim the verbosity of the verbose boot. > > > > Am I also missing an obvious reason most of the HDA output could not > > be eliminated since it is available y sysctl? > > It would be useful to know just which of it is available that way. Ian, With the (U.S.) holiday, I just got to this. The verbose boot presents an impressive amount of detail. I have not looked at it for some time and there is a LOT more there than list time I verbose booted. It's well over 24 KB of output.The sysctl presents all of the NID information for all three of my pcm devices and is all that is needed to customize them (as I did). It does a much nicer presentation, though, in a neat table instead of just a list. A great deal of the output repeats prior information, but in a different format that would be very convenient for debugging. All of the NID information and most of the rest really needs to be behind a .debug tunable so it does not always get dumped. Only when you really want it and have a larger buffer so it does not get lost. (I always hav a larger buffer on my workstations and the servers don't have HDA, so it's never been an issue. The reality is that there are a number of things in the verbose output that would be useful for tracking an error report and should be kept, but most of the verbosity looks to be of use in real driver debuging, so should not be part of the default verbose boot output. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com