From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 22:49:17 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 3449DE82; Thu, 22 Nov 2012 22:49:17 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id CFAC88FC08; Thu, 22 Nov 2012 22:49:16 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TbfZy-0007F7-LK; Thu, 22 Nov 2012 17:49:06 -0500 Date: Thu, 22 Nov 2012 17:49:06 -0500 From: Gary Palmer To: Kevin Oberman Subject: Re: Increasing the DMESG buffer.... Message-ID: <20121122224906.GE88593@in-addr.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Adrian Chadd , freebsd-stable@freebsd.org, Ian Smith , 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: Thu, 22 Nov 2012 22:49:17 -0000 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. > > 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 Gary