From owner-freebsd-current Wed Dec 2 09:28:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15092 for freebsd-current-outgoing; Wed, 2 Dec 1998 09:28:19 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15084 for ; Wed, 2 Dec 1998 09:28:17 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id JAA17722; Wed, 2 Dec 1998 09:28:04 -0800 (PST) (envelope-from dillon) Date: Wed, 2 Dec 1998 09:28:04 -0800 (PST) From: Matthew Dillon Message-Id: <199812021728.JAA17722@apollo.backplane.com> To: Steve Kargl Cc: green@unixhelp.org (Brian Feldman), freebsd-current@FreeBSD.ORG Subject: Re: Crash dump howto? References: <199812021659.IAA41596@troutmask.apl.washington.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I have sources from 2 days ago. I have version 1.74 of vfs_cluster.c :which is alleged to have fixed the problem. It doesn't. My sources :are cvsup'd from cvsup.freebsd.org. : :I can kill the system under heavy load with either and ELF or aout kernel. : :I can not get the system to produce a crash dump. : :So, the question remains how does one force a dump? : :-- :Steve This is what we do: options DDB options COMCONSOLE # serial console vs normal console options BREAK_TO_DEBUGGER #a BREAK on a comconsole goes to #DDB, if available. 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. 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. 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. Also make sure you are using a reasonably standardized /etc/rc that properly savecore's the dumps, and that /var/crash is big enough to hold the writeout (a bit more then the main memory size in free space must be available). -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message