Re: Increasing the DMESG buffer....
on 25/11/2012 02:08 Willem Jan Withagen said the following: On 25-11-2012 0:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. That would help, especially if we can get it in the beastie bootmenu options... Eh? I thought I already told about the tunable? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 25 November 2012 10:10, per...@pluto.rain.com wrote: Alexander Motin m...@freebsd.org wrote: On 25.11.2012 01:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. It is tunable. AFAIR that is it: kern.msgbufsize=65536 # Set size of kernel message buffer Yep. That tunable is available in 8.2 (not 8.1), and I think in all 9.x; dunno if it was ever MFC'd to the 7.x branch. The tunable was merged to stable/8 in March 2011 and first appeared in 8.3. It was never merged to stable/7. IIRC it should be quite easy to adopt those patches to stable/7. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Sun, Nov 25, 2012 at 05:20:52PM +1100, Ian Smith wrote: On Fri, 23 Nov 2012 11:33:21 +0100, Lars Engels wrote: Am 23.11.2012 05:50, schrieb Ian Smith: On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: [..] 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. Well that's interesting, excuse my assumption. But as downloaded: -rw-r--r-- 1 smithi smithi 82415 Nov 22 14:08 T61_dmesg.boot.10.works So is the default msgbufsize on 10 different to what mav@ just posted? kern.msgbufsize=65536 # Set size of kernel message buffer And if the PC-BSD 9.1-RCsomething one you refer to is: http://bsd-geek.de/FreeBSD/T61_dmesg.boot.9.works then that's only 37844 bytes and has most of its head missing, in fact starting only a screenful before the hda stuff that's most of the rest. IIRC I just uploaded /var/run/dmesg.boot pgpH27zmOFnuy.pgp Description: PGP signature
Re: Increasing the DMESG buffer....
On Sun, Nov 25, 2012 at 02:00:30PM +0300, Sergey Kandaurov wrote: On 25 November 2012 10:10, per...@pluto.rain.com wrote: Alexander Motin m...@freebsd.org wrote: On 25.11.2012 01:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. It is tunable. AFAIR that is it: kern.msgbufsize=65536 # Set size of kernel message buffer Yep. That tunable is available in 8.2 (not 8.1), and I think in all 9.x; dunno if it was ever MFC'd to the 7.x branch. The tunable was merged to stable/8 in March 2011 and first appeared in 8.3. It was never merged to stable/7. IIRC it should be quite easy to adopt those patches to stable/7. stable/7 will be out of support in 3 months. If someone is still using it now is the time to upgrade. http://www.freebsd.org/security/security.html#sup -- Mateusz Guzik mjguzik gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 23-11-2012 1:20, Kevin Oberman wrote: On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer gpal...@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 adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@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. 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. So we need to either expand the default buffer (not something I would want to do) or trim the verbosity of the verbose boot. Am I also missing an obvious reason most of the HDA output could not be eliminated since it is available y sysctl? Reason I asked for how to set a bigger buffer was booting a serverboard verbose And there is so much pci stuff dumped that it ran out of space. Plenty of unknown devices. There is no sound on this board. And usually that is the first thing that is asked for on this list, once one start reporting problems. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
I'm surprised it's not tunable via a kenv variable at boottime.. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 25-11-2012 0:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. That would help, especially if we can get it in the beastie bootmenu options... --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Thu, Nov 22, 2012 at 8:50 PM, Ian Smith smi...@nimnet.asn.au wrote: On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer gpal...@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 adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@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? So we need to either expand the default buffer (not something I would want to do) or trim the verbosity of the verbose boot. Am I also missing an obvious reason most of the HDA output could not be eliminated since it is available y sysctl? It would be useful to know just which of it is available that way. Ian, With the (U.S.) holiday, I just got to this. The verbose boot presents an impressive amount of detail. I have not looked at it for some time and there is a LOT more there than list time I verbose booted. It's well over 24 KB of output.The sysctl presents all of the NID information for all three of my pcm devices and is all that is needed to customize them (as I did). It does a much nicer presentation, though, in a neat table instead of just a list. A great deal of the output repeats prior information, but in a different format that would be very convenient for debugging. All of the NID information and most of the rest really needs to be behind a .debug tunable so it does not always get dumped. Only when you really want it and have a larger buffer so it does not get lost. (I always hav a larger buffer on my workstations and the servers don't have HDA, so it's never been an issue. The reality is that there are a number of things in the verbose output that would be useful for tracking an error report and should be kept, but most of the verbosity looks to be of use in real driver debuging, so should not be part of the default verbose boot output. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 25.11.2012 01:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. It is tunable. AFAIR that is it: kern.msgbufsize=65536 # Set size of kernel message buffer -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Fri, 23 Nov 2012 11:33:21 +0100, Lars Engels wrote: Am 23.11.2012 05:50, schrieb Ian Smith: On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: [..] 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. Well that's interesting, excuse my assumption. But as downloaded: -rw-r--r-- 1 smithi smithi 82415 Nov 22 14:08 T61_dmesg.boot.10.works So is the default msgbufsize on 10 different to what mav@ just posted? kern.msgbufsize=65536 # Set size of kernel message buffer And if the PC-BSD 9.1-RCsomething one you refer to is: http://bsd-geek.de/FreeBSD/T61_dmesg.boot.9.works then that's only 37844 bytes and has most of its head missing, in fact starting only a screenful before the hda stuff that's most of the rest. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
Alexander Motin m...@freebsd.org wrote: On 25.11.2012 01:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. It is tunable. AFAIR that is it: kern.msgbufsize=65536 # Set size of kernel message buffer Yep. That tunable is available in 8.2 (not 8.1), and I think in all 9.x; dunno if it was ever MFC'd to the 7.x branch. I was going to suggest adding a mention in the docs where verbose boot is described, but the only verbose boot mention I found is in Handbook 13.4.1, Kernel Boot Flags, which doesn't seem like a particularly good place to get into tunables. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
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 gpal...@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 adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Thu, 22 Nov 2012 08:12:17 +0100, Adrian Chadd adr...@freebsd.org wrote: On 21 November 2012 20:16, Ian Smith smi...@nimnet.asn.au wrote: 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 Is there a way to extract this topology information out of the driver without putting it in the verbose output? Adrian Maybe via /dev/sndstat. See hw.snd.verbose in sound(4). An additional level 5 for super verbose information? Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Wed, 21 Nov 2012 23:12:17 -0800, Adrian Chadd wrote: On 21 November 2012 20:16, Ian Smith smi...@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. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
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 smi...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 22 November 2012 06:30, Alexander Motin m...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@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. Also, isn't the entire verbose boot captured in /var/run/dmesg? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Thu, Nov 22, 2012 at 02:14:59PM -0800, Kevin Oberman wrote: On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@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. 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 Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer gpal...@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 adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@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. 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. So we need to either expand the default buffer (not something I would want to do) or trim the verbosity of the verbose boot. Am I also missing an obvious reason most of the HDA output could not be eliminated since it is available y sysctl? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer gpal...@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 adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@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? So we need to either expand the default buffer (not something I would want to do) or trim the verbosity of the verbose boot. Am I also missing an obvious reason most of the HDA output could not be eliminated since it is available y sysctl? It would be useful to know just which of it is available that way. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Increasing the DMESG buffer....
Hi, As a next question to my building this server. I'm nogt able to get a full verbose dmesg. Probably because the kernelbuffer for it is too small. I know there used to be a kernel option to increase it. But I can not find it with the setting in NOTES or any other place I looked Is it still there? Thanx, --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 2012-Nov-21 10:57:49 +0100, Willem Jan Withagen w...@digiware.nl wrote: Probably because the kernelbuffer for it is too small. I know there used to be a kernel option to increase it. But I can not find it with the setting in NOTES or any other place I looked # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 -- Peter Jeremy pgpwUscTboaAO.pgp Description: PGP signature
Re: Increasing the DMESG buffer....
On 2012-11-21 11:14, Peter Jeremy wrote: On 2012-Nov-21 10:57:49 +0100, Willem Jan Withagen w...@digiware.nl wrote: Probably because the kernelbuffer for it is too small. I know there used to be a kernel option to increase it. But I can not find it with the setting in NOTES or any other place I looked # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 Right, That was the one Thanx Peter --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
on 21/11/2012 15:20 Willem Jan Withagen said the following: On 2012-11-21 11:14, Peter Jeremy wrote: On 2012-Nov-21 10:57:49 +0100, Willem Jan Withagen w...@digiware.nl wrote: Probably because the kernelbuffer for it is too small. I know there used to be a kernel option to increase it. But I can not find it with the setting in NOTES or any other place I looked # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 Right, That was the one Alternatively you could set kern.msgbufsize tunable. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 2012-11-21 16:08, Andriy Gapon wrote: on 21/11/2012 15:20 Willem Jan Withagen said the following: On 2012-11-21 11:14, Peter Jeremy wrote: On 2012-Nov-21 10:57:49 +0100, Willem Jan Withagen w...@digiware.nl wrote: Probably because the kernelbuffer for it is too small. I know there used to be a kernel option to increase it. But I can not find it with the setting in NOTES or any other place I looked # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 Right, That was the one Alternatively you could set kern.msgbufsize tunable. That is a fresh new one for me. Now you tell me :) after I've started compiling a new kernel. Need to set that in loader.conf. Thanx, --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Wed, 2012-11-21 at 16:51 +0100, Willem Jan Withagen wrote: On 2012-11-21 16:08, Andriy Gapon wrote: on 21/11/2012 15:20 Willem Jan Withagen said the following: On 2012-11-21 11:14, Peter Jeremy wrote: On 2012-Nov-21 10:57:49 +0100, Willem Jan Withagen w...@digiware.nl wrote: Probably because the kernelbuffer for it is too small. I know there used to be a kernel option to increase it. But I can not find it with the setting in NOTES or any other place I looked # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 Right, That was the one Alternatively you could set kern.msgbufsize tunable. That is a fresh new one for me. Now you tell me :) after I've started compiling a new kernel. Need to set that in loader.conf. Thanx, --WjW You know what would be great? Have this value auto-tune itself upwards if bootverbose is true. The sound drivers now spit out so much stuff with bootverbose true that you need like a 128k buffer to see the early boot messages. -- Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
on 21/11/2012 18:01 Ian Lepore said the following: You know what would be great? Have this value auto-tune itself upwards if bootverbose is true. This sounds /potentially/ neat. The sound drivers now spit out so much stuff with bootverbose true that you need like a 128k buffer to see the early boot messages. I'd argue that snd_hda should not do that. It should use a different knob. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Wed, Nov 21, 2012 at 06:08:12PM +0200, Andriy Gapon wrote: on 21/11/2012 18:01 Ian Lepore said the following: You know what would be great? Have this value auto-tune itself upwards if bootverbose is true. This sounds /potentially/ neat. I do not want the bootverbose knob suddently change kernel memory layout. The sound drivers now spit out so much stuff with bootverbose true that you need like a 128k buffer to see the early boot messages. I'd argue that snd_hda should not do that. It should use a different knob. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org pgpEpqgbl43iM.pgp Description: PGP signature
Re: Increasing the DMESG buffer....
On Wed, 21 Nov 2012 18:08:12 +0200, Andriy Gapon wrote: on 21/11/2012 18:01 Ian Lepore said the following: You know what would be great? Have this value auto-tune itself upwards if bootverbose is true. This sounds /potentially/ neat. The sound drivers now spit out so much stuff with bootverbose true that you need like a 128k buffer to see the early boot messages. I'd argue that snd_hda should not do that. It should use a different knob. If I had a +1 I'd spend it on this one. Great when you need it, but .. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 2012-11-21 18:09, Ian Smith wrote: On Wed, 21 Nov 2012 18:08:12 +0200, Andriy Gapon wrote: on 21/11/2012 18:01 Ian Lepore said the following: You know what would be great? Have this value auto-tune itself upwards if bootverbose is true. This sounds /potentially/ neat. The sound drivers now spit out so much stuff with bootverbose true that you need like a 128k buffer to see the early boot messages. I'd argue that snd_hda should not do that. It should use a different knob. If I had a +1 I'd spend it on this one. Great when you need it, but .. Why bother... Memory is so cheap these days. We're talking about 64Kb being wasted. On average I would assume that there is more than this wasted in odd bits and pieces in the kernel. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Wed, 21 Nov 2012 18:25:22 +0100 Willem Jan Withagen w...@digiware.nl wrote: Why bother... Because FreeBSD also runs on hardware with minimal memory? Because FreeBSD is a stable, sane operating system and we want to keep it that way? Because it breaks POLA? Because it make developers act sloppy? I'm sorry (I'm not picking on you in particular, but this comment represents a growing trend in attitude), but more and more people today are becoming careless in the way they think (or not think). I do not want FreeBSD to suffer because of that. If you are a FreeBSD developer or user; be vigilant! Don't let the sloppyness silnently slip into or favorite operating system, or the way we handle it! /soapbox -- Torfinn Ingolfsen torfinn.ingolf...@getmail.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 21 November 2012 09:25, Willem Jan Withagen w...@digiware.nl wrote: Why bother... Memory is so cheap these days. We're talking about 64Kb being wasted. On average I would assume that there is more than this wasted in odd bits and pieces in the kernel. .. and some of us are actively trying to trim this waste down, as we're trying to get FreeBSD _back_ into devices that have 16MB of RAM. Please, don't assume RAM is free. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On Wed, 21 Nov 2012 19:41:42 +0100, Torfinn Ingolfsen torfinn.ingolf...@getmail.no wrote: On Wed, 21 Nov 2012 18:25:22 +0100 Willem Jan Withagen w...@digiware.nl wrote: Why bother... Because FreeBSD also runs on hardware with minimal memory? yes, but defaults should be for the masses and it is tunable for the rest Because FreeBSD is a stable, sane operating system and we want to keep it that way? yes, but how does an increased buffer bring instability? You can use your argument for every commit. Because it breaks POLA? how? Because it make developers act sloppy? How do you go from increasing a buffer to hold all the data which solves a practical problem to people being sloppy? I'm sorry (I'm not picking on you in particular, but this comment represents a growing trend in attitude), but more and more people today are becoming careless in the way they think (or not think). I do not want FreeBSD to suffer because of that. If you are a FreeBSD developer or user; be vigilant! Don't let the sloppyness silnently slip into or favorite operating system, or the way we handle it! /soapbox IMHO these arguments are more about general feelings than actual to the point remarks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
.. 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? adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 2012-11-21 21:08, 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? My first ever self build system was a Z80 which started at 2Kbyte EPROM and 2K RAM. which was huge at that time. (1980's) Later I made bankswitch to have some 32K ROM and 2* 32K RAM. Boy was that a lot of space. The first ever FreeBSD I/we ran, was 1.0(.2??) on a lowly i486 with 16Mb of memory, with a 16 port serialcard with 14k4 modems. It ran Bnews with a full feed on 2 1.6Gb disks... Was mail server for 1000 customers. It ran slip for IP access... So sure I understand where we are coming from. And I'm still tinkering in removing bloat that I will not ever use, even though my home server has 35T of storage. :) But hen still I agree with Ronald that we need to cater for the mass, which means we keep in mind what just about most everybody is running. And that is certainly not embedded with 16Mb NOR and 32Mb RAM. But then again I do appreciate you setting me straight on that waste is never a good thing. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: Increasing the DMESG buffer....
+1 (RAM is neither free nor abundant.) Increasing the default buffers, stack or heap use, should be carefully considered. There was a discussion about providing guidance/examples for loader.conf and sysctl.conf for various anticipated uses: firewall, workstation, servers, routers whether single/dual/multi core; perhaps this is where calls for values other than those necessary to get a basic general purpose machine working, should be? We manage servers providing all of: samba, squid, dovecot, sendmail, ldap, heimdal, apache on low-energy boxes with 1G RAM, and over 8 years FreeBSD has proven that it has the power to serve. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
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
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 22/11/2012, at 14:46, Ian Smith smi...@nimnet.asn.au wrote:
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 ..
Wouldn't it be better to expose that stuff via a sysctl directly (ie the sysctl
holds the actual data)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Re: Increasing the DMESG buffer....
Dearest people, I'm trying to get FreeBSD (back) into a couple orders of magnitude more devices than you're thinking about. When we talk about the masses, let's keep in mind that we have different ideas of what the masses are. I'm trying to keep all of them in mind, rather than just the subset that want to run FreeBSD on their desktop or high end servers. Adrian On 21 November 2012 16:59, Willem Jan Withagen w...@digiware.nl wrote: On 2012-11-21 21:08, 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? My first ever self build system was a Z80 which started at 2Kbyte EPROM and 2K RAM. which was huge at that time. (1980's) Later I made bankswitch to have some 32K ROM and 2* 32K RAM. Boy was that a lot of space. The first ever FreeBSD I/we ran, was 1.0(.2??) on a lowly i486 with 16Mb of memory, with a 16 port serialcard with 14k4 modems. It ran Bnews with a full feed on 2 1.6Gb disks... Was mail server for 1000 customers. It ran slip for IP access... So sure I understand where we are coming from. And I'm still tinkering in removing bloat that I will not ever use, even though my home server has 35T of storage. :) But hen still I agree with Ronald that we need to cater for the mass, which means we keep in mind what just about most everybody is running. And that is certainly not embedded with 16Mb NOR and 32Mb RAM. But then again I do appreciate you setting me straight on that waste is never a good thing. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Increasing the DMESG buffer....
On 21 November 2012 20:16, Ian Smith smi...@nimnet.asn.au wrote: 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 Is there a way to extract this topology information out of the driver without putting it in the verbose output? Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
