Increasing the DMESG buffer....

[Ian Smith]

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