Date: Sun, 18 Aug 2013 13:56:57 +0200 From: Dominic Fandrey <kamikaze@bsdforen.de> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-stable@freebsd.org Subject: Re: System doesn't dump Message-ID: <5210B689.2030703@bsdforen.de> In-Reply-To: <20130529071141.GA90903@icarus.home.lan> References: <51A5A322.1020503@bsdforen.de> <20130529071141.GA90903@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5210B689.2030703>