Increasing the DMESG buffer....

[Alexander Motin]

On 22.11.2012 12:53, Ian Smith wrote:
> On Wed, 21 Nov 2012 23:12:17 -0800, Adrian Chadd wrote:
>   > On 21 November 2012 20:16, Ian Smith <smithi at nimnet.asn.au> wrote:
>   > > On Wed, 21 Nov 2012 12:08:42 -0800, Adrian Chadd wrote:
> [..]
>   > > 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
>   >
>   > Is there a way to extract this topology information out of the driver
>   > without putting it in the verbose output?
>
> We should be asking Alexander, cc'd.  I only have a snd_ich here, where
> hw.snd.verbose=3 is as rich as it gets, 105 lines incl. file versions.

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.

-- 
Alexander Motin