From owner-freebsd-stable@FreeBSD.ORG Sat Nov 24 23:19:28 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 5072FEA6; Sat, 24 Nov 2012 23:19:28 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (smtp.digiware.nl [31.223.170.169]) by mx1.freebsd.org (Postfix) with ESMTP id BEE6F8FC08; Sat, 24 Nov 2012 23:19:27 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id B532215343E; Sun, 25 Nov 2012 00:19:01 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U4KuzDZn6y2; Sun, 25 Nov 2012 00:19:01 +0100 (CET) Received: from [192.168.10.10] (vaio [192.168.10.10]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id BF93715343B; Sun, 25 Nov 2012 00:19:00 +0100 (CET) Message-ID: <50B155E9.3010505@digiware.nl> Date: Sun, 25 Nov 2012 00:19:05 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: Increasing the DMESG buffer.... 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sat, 24 Nov 2012 23:19:28 -0000 On 23-11-2012 1:20, 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. >>> >>> 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. > > 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? Reason I asked for how to set a bigger buffer was booting a serverboard verbose.... And there is so much pci stuff dumped that it ran out of space. Plenty of unknown devices..... There is no sound on this board. And usually that is the first thing that is asked for on this list, once one start reporting problems. --WjW