Re: System doesn't dump
After a long time I got my system to make all the right noises (I think), still without it actually dumping, though. On 29/05/2013 09:11, Jeremy Chadwick wrote: On Wed, May 29, 2013 at 08:41:38AM +0200, Dominic Fandrey wrote: I have a number of actions that reliably panic the system, such as performing shutdown -p (yes I'm booting into an inconsistent file system every time). Both with my notebook and my workstation. However I cannot get the system to dump. dumpdir=/var/crash and I've tried ada0s2b, /dev/ada0s2b, label/5swap, /dev/label/5swap and AUTO for dumpdev to no avail. The swap partition is 16g, the machines have 8g RAM and there's plenty of hard disk space available for /var/crash. I'm looking for that secret, undocumented trigger, that makes the system dump if a panic occurs. Once upon a time dumping just worked if the swap partition was large enough. I miss those olden days. Foremost: the fact you did not disclose your FreeBSD version (and SVN rev if you have it) nor architecture is disappointing. It matters more than you think. Please disclose it. Branch is stable/9 revision r254418. Architecture is amd64: # uname -a FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254418: Fri Aug 16 22:15:55 CEST 2013 root@mobileKamikaze.norad:/usr/obj/HP6510b-91/amd64/usr/src/sys/HP6510b-91 amd64 If you have VGA console access, try dropping to db and issuing the command call doadump (possibly preceded by panic). KMS. So no ... If you have serial console access, there are ways to drop to ddb but it depends on your kernel config (look for BREAK_TO_DEBUGGER and ALT_BREAK_TO_DEBUGGER in /sys/conf/NOTES). Break with serial, by the way, means a serial-level break signal (often why I prefer ALT_BREAK_TO_DEBUGGER). No serial access. Unless this is somehow possible over USB. ... See sysctl debug.ddb.scripting.scripts for what should get automatically done on a panic. This may or may not be affected by ddb_enable=yes in rc.conf (which mandates DDB being enabled in your kernel) -- I can't remember though, so someone else may want to comment. # sysctl debug.ddb debug.ddb.capture.bufsize: 49152 debug.ddb.capture.inprogress: 0 debug.ddb.capture.maxbufsize: 5242880 debug.ddb.capture.bufoff: 0 debug.ddb.scripting.unscript: debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo debug.ddb.textdump.do_version: 1 debug.ddb.textdump.do_panic: 1 debug.ddb.textdump.do_msgbuf: 1 debug.ddb.textdump.do_ddb: 1 debug.ddb.textdump.do_config: 1 debug.ddb.textdump.pending: 0 If your issue is that the kernel actually *does* dump memory to swap but that on boot-up savecore(8) doesn't recover ... I cannot be perfectly positive, because a minidump is written in no time, but I do not think that is the issue. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: System doesn't dump
On 30/05/2013 15:02, John Baldwin wrote: On Wednesday, May 29, 2013 2:41:38 am Dominic Fandrey wrote: I have a number of actions that reliably panic the system, such as performing shutdown -p (yes I'm booting into an inconsistent file system every time). Both with my notebook and my workstation. However I cannot get the system to dump. dumpdir=/var/crash and I've tried ada0s2b, /dev/ada0s2b, label/5swap, /dev/label/5swap and AUTO for dumpdev to no avail. The swap partition is 16g, the machines have 8g RAM and there's plenty of hard disk space available for /var/crash. I'm looking for that secret, undocumented trigger, that makes the system dump if a panic occurs. Once upon a time dumping just worked if the swap partition was large enough. I miss those olden days. Does /dev/dumpdev exist and point to your swap partition after booting? # ll /dev/dumpdev lrwxr-xr-x 1 root wheel16B 18 Aug 14:42 /dev/dumpdev@ - /dev/label/5swap # ll /dev/label/5swap crw-rw 1 root operator 0x72 18 Aug 14:42 /dev/label/5swap Yes, looks like it. And it's a genuine swap partition: swapinfo Device 1K-blocks UsedAvail Capacity /dev/label/5swap 167772120 16777212 0% -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: System doesn't dump
On Wednesday, May 29, 2013 2:41:38 am Dominic Fandrey wrote: I have a number of actions that reliably panic the system, such as performing shutdown -p (yes I'm booting into an inconsistent file system every time). Both with my notebook and my workstation. However I cannot get the system to dump. dumpdir=/var/crash and I've tried ada0s2b, /dev/ada0s2b, label/5swap, /dev/label/5swap and AUTO for dumpdev to no avail. The swap partition is 16g, the machines have 8g RAM and there's plenty of hard disk space available for /var/crash. I'm looking for that secret, undocumented trigger, that makes the system dump if a panic occurs. Once upon a time dumping just worked if the swap partition was large enough. I miss those olden days. Does /dev/dumpdev exist and point to your swap partition after booting? -- John Baldwin ___ 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
System doesn't dump
I have a number of actions that reliably panic the system, such as performing shutdown -p (yes I'm booting into an inconsistent file system every time). Both with my notebook and my workstation. However I cannot get the system to dump. dumpdir=/var/crash and I've tried ada0s2b, /dev/ada0s2b, label/5swap, /dev/label/5swap and AUTO for dumpdev to no avail. The swap partition is 16g, the machines have 8g RAM and there's plenty of hard disk space available for /var/crash. I'm looking for that secret, undocumented trigger, that makes the system dump if a panic occurs. Once upon a time dumping just worked if the swap partition was large enough. I miss those olden days. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: System doesn't dump
On Wed, May 29, 2013 at 08:41:38AM +0200, Dominic Fandrey wrote: I have a number of actions that reliably panic the system, such as performing shutdown -p (yes I'm booting into an inconsistent file system every time). Both with my notebook and my workstation. However I cannot get the system to dump. dumpdir=/var/crash and I've tried ada0s2b, /dev/ada0s2b, label/5swap, /dev/label/5swap and AUTO for dumpdev to no avail. The swap partition is 16g, the machines have 8g RAM and there's plenty of hard disk space available for /var/crash. I'm looking for that secret, undocumented trigger, that makes the system dump if a panic occurs. Once upon a time dumping just worked if the swap partition was large enough. I miss those olden days. Foremost: the fact you did not disclose your FreeBSD version (and SVN rev if you have it) nor architecture is disappointing. It matters more than you think. Please disclose it. Onward ho... If you have VGA console access, try dropping to db and issuing the command call doadump (possibly preceded by panic). If you have serial console access, there are ways to drop to ddb but it depends on your kernel config (look for BREAK_TO_DEBUGGER and ALT_BREAK_TO_DEBUGGER in /sys/conf/NOTES). Break with serial, by the way, means a serial-level break signal (often why I prefer ALT_BREAK_TO_DEBUGGER). After doing call doadump you should definitely see the kernel dumping memory to swap (it gives a progress indicator of sorts). Google for the phrase call doadump and look at some of the results to get an idea of what the output normally is during that phase, for comparison. If you don't see such, I'm sure many of the kernel folks here can help figure out why. See sysctl debug.ddb.scripting.scripts for what should get automatically done on a panic. This may or may not be affected by ddb_enable=yes in rc.conf (which mandates DDB being enabled in your kernel) -- I can't remember though, so someone else may want to comment. If your issue is that the kernel actually *does* dump memory to swap but that on boot-up savecore(8) doesn't recover the memory dump and populate relevant files in /var/crash: that's a separate issue that has been discussed for probably 10 years or longer with (to my knowledge) no definitive explanation. Theories presented (going off of memory here) were that that something ended up writing over parts of the panic metadata on the swap disk/slice/etc. and thus savecore(8) finds nothing. This is why rc scripts/etc. have to make sure to look for the swap panic metadata and run savecore(8) **before** issuing dumpon(8). My opinion, others' may vary: Stick with using dumpdev=auto in rc.conf, assuming you have a /etc/fstab entry of swap somewhere. Swap should ideally be a partition or slice, not something abstracted out by other layers (see above paragraph for why I advocate that, but my additional opinion is that when it comes to getting a kernel dump and system configurations, KISS principle applies heavily. If your system is crashing, the last thing you want to deal with is why you can't get a kernel dump -- you could spend more time doing that than you do getting the panic info + debugging the actual crash), but again, this is my own opinion and there are legitimate other opinions as well -- I just follow what I do because I know it works. Likewise I always get wary of people's setups when I start seeing labels mentioned. *waves cane* Screw all this newfandangled stuff. :-) -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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
