From owner-freebsd-stable@FreeBSD.ORG Fri Nov 23 10:33:24 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 91553295 for ; Fri, 23 Nov 2012 10:33:24 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 105F78FC16 for ; Fri, 23 Nov 2012 10:33:24 +0000 (UTC) Received: from 0x20.net (0x20.net [217.69.76.212]) (Authenticated sender: lala) by mail.0x20.net (Postfix) with ESMTPA id CBFA66A6001 for ; Fri, 23 Nov 2012 11:33:21 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 23 Nov 2012 11:33:21 +0100 From: Lars Engels To: Subject: Re: Increasing the DMESG buffer.... 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> Message-ID: <1ab82c79bc6d72fdaa90e7ed0c794f5f@mail.0x20.net> X-Sender: lars.engels@0x20.net User-Agent: Roundcube Webmail/0.7 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: Fri, 23 Nov 2012 10:33:24 -0000 Am 23.11.2012 05:50, schrieb Ian Smith: > 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? No, I was creating the dmesg on a vanilla FreeBSD 10-CURRENT kernel and the other one on PC-BSD 9.1-RCsomething.