Date: Thu, 22 Nov 2012 14:05:28 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: Ronald Klop <ronald-freebsd8@klop.yi.org>, freebsd-stable@freebsd.org, Ian Smith <smithi@nimnet.asn.au>, Andriy Gapon <avg@icyb.net.ua> Subject: Re: Increasing the DMESG buffer.... Message-ID: <CAJ-Vmo=UOTu0KG6yHjZ_gBB4HGSGNJOAhn3HT-8gNsh_=ih7Yg@mail.gmail.com> In-Reply-To: <50AE36FF.7080106@FreeBSD.org> 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> <op.wn4141f88527sy@212-182-167-131.ip.telfort.nl> <CAJ-VmomREO6uj_izmD%2Bp90cFn=AQcz7UbZNkX8PVnU5mG_8ufQ@mail.gmail.com> <20121122144400.M21191@sola.nimnet.asn.au> <CAJ-Vmonk2RS=FwpgVHpeuFF5jf%2BSjE2Hv8kOFBrDCkv-=hTYSg@mail.gmail.com> <20121122213328.J21191@sola.nimnet.asn.au> <50AE36FF.7080106@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 November 2012 06:30, Alexander Motin <mav@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. adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=UOTu0KG6yHjZ_gBB4HGSGNJOAhn3HT-8gNsh_=ih7Yg>