Increasing the DMESG buffer....

[Lars Engels]

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 <gpalmer at freebsd.org> 
> 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 
> <adrian at freebsd.org> wrote:
>  > >> > On 22 November 2012 06:30, Alexander Motin <mav at freebsd.org> 
> 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.