From owner-freebsd-questions Sun May 31 20:25:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA17601 for freebsd-questions-outgoing; Sun, 31 May 1998 20:25:47 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA17566 for ; Sun, 31 May 1998 20:25:38 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id MAA10949; Mon, 1 Jun 1998 12:55:35 +0930 (CST) Message-ID: <19980601125534.M22406@freebie.lemis.com> Date: Mon, 1 Jun 1998 12:55:34 +0930 From: Greg Lehey To: Joe McGuckin , questions@FreeBSD.ORG Subject: Re: Enabling crash dumps References: <199806010255.TAA02002@monk.via.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199806010255.TAA02002@monk.via.net>; from Joe McGuckin on Sun, May 31, 1998 at 07:55:40PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 31 May 1998 at 19:55:40 -0700, Joe McGuckin wrote: > > What do I need to do to enable crash dumps? >From "The Complete FreeBSD", second edition (http://www.cdrom.com/titles/os/bsdbook2.htm), page 87: Sometimes the system gets into so much trouble that it can't continue. It should notice this situation and stop more or less gracefully: you might see a message like panic: free vnode isn't Syncing disks 14 13 9 5 5 5 5 5 5 5 giving up dumping to dev 20001 offset 0 dump 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 succeeded Automatic reboot in 15 seconds - press a key on the console to abort Reboooting... Just because the system has panicked doesn't mean that you should panic too. It's a sorry fact of life that software contains bugs. Many commercial systems just crash when they hit a bug, and you never know why, or they print a message like General protection error, which doesn't tell you very much either. When a UNIX system panics, it tells you why--in this case here, the reason is free vnode isn't. You may not be any the wiser for a message like this (it tells you that the file system handling has got confused about the current state of storage on a disk), but other people might. In particular, if you do get a panic and you want to ask, say, the FreeBSD hackers, please don't just say ``My system panicked, what do I do?'' The answer--if you get one--will be ``What was the panic string?'' After panicking, the system tries to write file system buffers back to disk so that they don't get lost. This is not always possible, as we see on the second line of this example. It started off with 14 buffers to write, but it only managed to write 9 of them, possibly because it was confused about the state of the disk. This can mean that you will have difficulties after rebooting, but it might also mean that the system was wrong in its assumptions about the number of buffers needed to be written. In addition to telling you the cause of the panic, FreeBSD will optionally copy the current contents of memory to the swap file for post-mortem analysis. This is called dumping the system, and is shown on the next two lines. In order to enable dumping, you need to specify where the dump should be written. In /etc/rc.conf, you will find: # Set to the name of the device for kernel crashdumps, or `off' to # disable any statically configured dumpdev, or NO for no change. # The device should normally be one of the swap devices specified # in /etc/fstab. dumpdev=NO # Set to YES if you want kernel crashdumps to be saved for debugging savecore=NO To enable dumping, change the last lines to: dumpdev=/dev/wd0s1b # Set to YES if you want kernel crashdumps to be saved for debugging savecore=YES Make sure that the name of the dumpdev corresponds to a swap partition with at least as much space as your total memory. You can use pstat to check this: # pstat -s Device 1024-blocks Used Avail Capacity Type /dev/wd0s1b 51200 50108 1028 98% Interleaved /dev/sd0b 66036 51356 14616 78% Interleaved /dev/sd2b 204800 51220 153516 25% Interleaved Total 321844 152684 169160 47% This particular machine has 96 MB of main memory, so only the swap partition on /dev/sd2b has enough space for it. In addition, ensure you have a directory /var/crash. After rebooting, the system first checks the integrity of the file systems, then it checks for the presence of a dump. If it finds one, it copies the dump and the current kernel to /var/crash. It's always worth enabling dumping, assuming your swap space is at least as large as your memory. You can analyze the dumps with kgdb--see the online handbook for more details. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message