Date: Fri, 23 Nov 2012 11:33:21 +0100 From: Lars Engels <lars.engels@0x20.net> To: <freebsd-stable@freebsd.org> Subject: Re: Increasing the DMESG buffer.... Message-ID: <1ab82c79bc6d72fdaa90e7ed0c794f5f@mail.0x20.net> In-Reply-To: <20121123150719.M21191@sola.nimnet.asn.au> References: <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> <CAJ-Vmo=UOTu0KG6yHjZ_gBB4HGSGNJOAhn3HT-8gNsh_=ih7Yg@mail.gmail.com> <CAN6yY1v1AdhgqQfONbDAEueU2wnFZDO8GvegRzq10y0yoj8kDg@mail.gmail.com> <20121122224906.GE88593@in-addr.com> <CAN6yY1sK3U=18ovFYPAViuMxTDCm2qZ-msLmM7Zgymx=u6ga4w@mail.gmail.com> <20121123150719.M21191@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org> wrote: > > >> > 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. > > >> > > >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1ab82c79bc6d72fdaa90e7ed0c794f5f>