System doesn't dump
Dominic Fandrey
kamikaze at bsdforen.de
Sun Aug 18 11:57:01 UTC 2013
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 at 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?
More information about the freebsd-stable
mailing list