From owner-freebsd-current Wed Dec 2 09:53:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA17257 for freebsd-current-outgoing; Wed, 2 Dec 1998 09:53:33 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA17252 for ; Wed, 2 Dec 1998 09:53:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.9.1/8.9.1) id KAA55752; Wed, 2 Dec 1998 10:01:17 -0800 (PST) (envelope-from sgk) From: Steve Kargl Message-Id: <199812021801.KAA55752@troutmask.apl.washington.edu> Subject: Re: Crash dump howto? In-Reply-To: <199812021728.JAA17722@apollo.backplane.com> from Matthew Dillon at "Dec 2, 1998 9:28: 4 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Wed, 2 Dec 1998 10:01:16 -0800 (PST) Cc: green@unixhelp.org, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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