Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Jun 1998 12:55:34 +0930
From:      Greg Lehey <grog@lemis.com>
To:        Joe McGuckin <joe@via.net>, questions@FreeBSD.ORG
Subject:   Re: Enabling crash dumps
Message-ID:  <19980601125534.M22406@freebie.lemis.com>
In-Reply-To: <199806010255.TAA02002@monk.via.net>; from Joe McGuckin on Sun, May 31, 1998 at 07:55:40PM -0700
References:  <199806010255.TAA02002@monk.via.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



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