From owner-freebsd-stable@FreeBSD.ORG Thu Nov 22 04:16:57 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 384D3514; Thu, 22 Nov 2012 04:16:57 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9D0CA8FC08; Thu, 22 Nov 2012 04:16:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id qAM4GjGp061028; Thu, 22 Nov 2012 15:16:46 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 22 Nov 2012 15:16:45 +1100 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: Increasing the DMESG buffer.... In-Reply-To: Message-ID: <20121122144400.M21191@sola.nimnet.asn.au> References: <50ACA59D.3080809@digiware.nl> <20121121101411.GG4535@server.rulingia.com> <50ACD522.7000706@digiware.nl> <50ACEE5B.8000901@FreeBSD.org> <50ACF891.4050105@digiware.nl> <1353513692.69940.7.camel@revolution.hippie.lan> <50ACFC6C.8070506@FreeBSD.org> <20121122040251.G21191@sola.nimnet.asn.au> <50AD0E82.3070706@digiware.nl> <20121121194142.8c4bf7d1977f13801a021ccc@getmail.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Andriy Gapon , freebsd-stable@freebsd.org, Lars Engels , 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 04:16:57 -0000 On Wed, 21 Nov 2012 12:08:42 -0800, Adrian Chadd wrote: > .. because some of us like kernel behaviour to be predictable and > controllable, rather than 'just be dynamic here, what could possibly > go wrong.' > > Just bump the default kernel buffer size up to 64k and leave it > hard-coded like that. Us embedded people can drop that down to > something smaller. > > There. Problem solved, right? Well maybe, but I still tend to take Andriy's point about snd_hda. For example, Lars Engels posted several verbose dmesgs the other day, not to do with sound, one of which was: http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works T61_dmesg.boot.10.works (file 1 of 2) lines 1813-1861/1861 byte 82415/82415 Cutting just the hdaa0, pcm0 and pcm1 stuff results in: hda_pcm.verbose (file 2 of 2) lines 712-760/760 byte 28531/28531 Noting that this is way over 64k and not atypical for a 2 core laptop, we see 40.8% of the lines and 34.6% of the bytes are due to sound stuff. Dumping all nodes and channels is incredibly useful for folks needing to rewire something to get various jacks working and such, but I'd argue is way overkill for a 'normal' verbose boot. See acpi(4) for examples of selectively logging ACPI_DEBUG components with debug.acpi.{layer,level} and be very glad all of that doesn't appear in every verbose boot .. cheers, Ian