~4Dgifts/toolbox/src/swtools/KrnlCrashDBG README
type:
man -d crpt.1
to view the man page for the crash report script
To generate a crash report:
cd /var/adm/crash (/usr/adm/crash in IRIX 4.*)
Example:
If you have a unix.1 and a vmcore.1.comp, it's
easiest just to run crpt with "1" as the arguement.
Also, you'll have to be root to read the core files or
you'll have to change the permissions on the files.
% su
# crpt 1
README for crpt
This "crpt" script hails from the INSIGHT system now available thru the
customer support division at sgi. the following problem description is
the kind of thing crpt can help to pinpoint. (If nothing else, do what
the man page below describes and then call up the Technical Assistance
Cente at 1-800-800-4744 and the data generated by running the crpt
script can help the TAC people help you solve the problem you're having.)
>| The system is an 4D/80GT (originally upgraded from a 4D/70GT). After
>| running the power-on diagnostics, the system spits out the following:
>|
>| PANIC: KERNAL FAULT
>| pc: 0x8001f73c, ep: 800e43c8, exc code 28 databus error
>| bad address 0x1000d0c8, cause: 0x3000041c <ce1ce0 ip3>
>| sr: 0xf804 <im6, im5, im4, im3, iep>
>|
>| After all of that, it does a dump and asks for a reset.
>|
>| We suspect that it is a hardware problem with one of the graphics boards,
>| but were wondering if someone out there in SGI land could narrow it down
>| to a specific board. Needless to say, the system is not under maintenance,
>| and some of the boards are refurbished and not purchased directly from SGI.
>Your best bet is to run dbx or dis on that part of the kernel (0x8001f73c),
>the routine name might help spot the problem. Doing a full backtrace
>on the save crash file (in /usr/adm/crash) would be even more helpful;
>the output from uname -a and/or versions -vn eoe1 would help us know
>which OS release you have.
If you are able to boot, you can run the following "crpt" script
which will do all of the things just mentioned automatically -
INSIGHT(1) UNIX System V INSIGHT(1)
NAME
crpt - Kernel core file report generator
SYNOPSIS
/usr/sbin/crpt -n [unix.N] [vmcore.N] or [N]
DESCRIPTION
crpt generates a report from kernel core files that can aid
your support provider in determining the cause of a system
crash. The report is saved in current directory as
"Crash_N.rpt" (Where "N" is the number of the dump file as
specified by /usr/adm/crash/bounds).
When a system crashes, it saves the contents of physical
memory and a copy of the kernel that was running. savecore
places these files in /usr/adm/crash. If your system has
crashed and you do not have unix.N and vmcore.N in
/usr/adm/crash, make sure your primary swap space on your
system disk is at least as large as your physical memory and
that you have at least that much free space in your /usr
partition (see savecore(1M)). Save unix.N and vmcore.N to
tape in case indepth debugging is required. Usually only a
kernel expert with access to the SGI source code can
accurately debug these core files. crpt drives the dbx
debugger through the basic steps a kernel expert would start
with when debugging a system crash. The dbx(1) debugger
must be installed for crpt to run. The report can be
included in a call logged through electronic services or
emailed or faxed to your local support provider.
crpt provides the following information:
1) Report System Info:
-The full path of the given core files
-Output of the utsname data structure to provide
system information:
If the script is run on the crashing system, it
will provide additional hardware and software
information. The output from "hinv" and
"versions -b" will be incorporated into the
script.
2) Formatted output from the kernel's error buffer.
This buffer contains errors messages that are
flushed to the system's error log
(/usr/adm/SYSLOG), but this buffer is often not
flushed when the system crashes.
3) Print the name of the program that was running
Page 1 (printed 10/11/92)
INSIGHT(1) UNIX System V INSIGHT(1)
at the time of the crash and the process id of
that program.
4) Print a kernel stack trace on the current
process id with the "print_exception_frame"
variable set. This will help trace the
functions called which lead up to the crash.
If there was an exception, the contents of the
exception frame (exception context) will be
printed out above the function which trapped
into the kernel.
5) Disassemble the code surrounding the exception
program counter. This will output the name of
the routine the system crashed in and the line
number in the source code.
6) Output for 'netstat -m' can be viewed by the -n
option.
7) Output for 'netstat -n' can be viewed by the -n
option.
OPTIONS
Command line options are described below.
-n The -n option turns on netstat -m and -s reports (see
netstat(1)).
SEE ALSO
savecore(1M), dbx(1), netstat(1)
Documentation
Reference
OR, ...