Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Dec 1998 10:01:16 -0800 (PST)
From:      Steve Kargl <sgk@troutmask.apl.washington.edu>
To:        dillon@apollo.backplane.com (Matthew Dillon)
Cc:        green@unixhelp.org, freebsd-current@FreeBSD.ORG
Subject:   Re: Crash dump howto?
Message-ID:  <199812021801.KAA55752@troutmask.apl.washington.edu>
In-Reply-To: <199812021728.JAA17722@apollo.backplane.com> from Matthew Dillon at "Dec 2, 1998  9:28: 4 am"

next in thread | previous in thread | raw e-mail | index | archive | help
According to Matthew Dillon:
> 
> :
> :So, the question remains how does one force a dump?
> :
> :-- 
> :Steve
> 
>     This is what we do:
> 
> options         DDB

I have this option, and can break to the debugger.

> 
>     And in /etc/rc.conf.local:
> 
> dumpdev="/dev/sd0b"
> 
>     Make sure the dump device (typically primary swap) is at least as large
>     as your main memory or the system will not be able to dump.
> 

I have tried /dev/da0s1b, /dev/da1s1b, and /dev/da1b with appropriately
labelled disk.  da0s1b is 500 MB in size and da1s1b is 700 MB in size.
I have 256 MB of main memory.

>     If the system farts, it will break into the debugger on the
>     serial console (make sure whatever you connect to the serial console is
>     itself secure!).  From the ddb> prompt you can usually 'panic'.  Sometimes
>     it takes a 'panic' followed by an extra return, but be careful not to
>     interrupt the dump in-progress because a return will also abort that.

db>panic
panic: from debugger
mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
boot() called on CPU #1
(da1:ahc0:0:2:0) SYNCHRONIZE CACHE.  CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ahc0:0:2:0) error code 0

dumping to dev 409, offset 907232

Fatal trap 12: page fault while in kernel mode
mp_lock = 01000003; cpuid = 1; lapic.id = 00000000
fault virtual address     = 0x20
fault code                = supervisor read, page not present
instruction pointer       = 0x8:0x20
stack pointer             = 0x10:0xf9232998
frame pointer             = 0x10:0x0
code segment              = base 0x0, limit 0xfffff, type 0x1b
                          = DPL 0, pres 1, def32, 1, gran 1
process eflags            = interrupt enabled, resume, IOPL = 0
current process           = 95350 (procmail)
interrupt mask            = net tty bio cam   <- SMP: XXX
kernel: type 12 trap, code = 0
Stopped at _Debugger+0x35:   movb $0,_in_Debugger.98
db> panic

Reach for reset button.


>     The debug monitor can also be used to do a simple stack backtrace, ps,
>     and a few other things before you panic the machine.  This can be useful
>     if the dump fails to work.

I've provided strack traces.  There are a few hundred processes.
The dump never seems to actually happen.


-- 
Steve

finger kargl@troutmask.apl.washington.edu
http://troutmask.apl.washington.edu/~clesceri/kargl.html

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812021801.KAA55752>