Solaris system crash dumps
Enabling in Solaris 2.6 (disabled by default):
Uncomment last 6 lines in /etc/init.d/sysetup
Enabling in Solaris 7 and Solaris 8 (enabled by default):
/usr/sbin/dumpadm -y
With dumpadm, the dump device
should be your system swap partition so that no file system information
is overwritten by the dump. Crash dumps are usually about 35% of
physical RAM, although they may be 80% to 90% of physical RAM in
certain
cases. The savecore directory should be large enough to accommodate
these large crash dumps.
If you receive "initial dump header corrupt" messages in /var/adm/messages, check dumpadm's dump device and make sure
it is a valid filesystem. In one instance, dumpadm was configured for the old
swap partition, not the new swap partition under volume management.
To report a crash dump, you need a symbolic traceback for it to be
useful to the person looking at it. Type the following:
cd /var/crash/`hostname`
echo '$c' | adb -k vmunix.0 vmcore.0
Sun's Solaris
Crash Analysis Tool (Solaris CAT) is the best tool to analyze crash
dumps. Sun's Initial System Crash Dump Analysis (iscda.sh)
tool may also be used to examine crash dumps. Example iscda.sh usage:
./iscda.sh unix.0 vmcore.0 > iscda.out
You may also force system crashes in Solaris to test your crash dump
configuration.
32-bit systems:
adb -wk
rootdir/W0
cd /
64-bit systems:
adb -wk
rootdir/Z0
cd /
Another method using adb:
adb -kw /dev/ksyms /dev/mem
rootdir/X
rootdir/W 0
$q
cd /
Another method using uadmin
(performs a sync and returns
to
the "ok" prompt):
uadmin 2 0
Back to brandonhutchinson.com.
Last modified: 10/13/2003