CRASH(8) GENIX Programmer's Manual CRASH(8)
NAME
crash - what happens when the system crashes
DESCRIPTION
This section explains what happens when the system crashes and how
you can analyze crash dumps.
When the system crashes voluntarily it prints a message of the form
panic: why i gave up the ghost
on the console, takes a dump on a mass storage peripheral, and then
invokes an automatic reboot procedure as described in reboot(8).
(If auto-reboot is disabled on the switch pack of the machine the
system will simply halt at this point.) Unless some unexpected
inconsistency is encountered in the state of the file systems due to
hardware or software failure the system will then resume multi-user
operations.
The system has a large number of internal consistency checks; if one
of these fails, then it will panic with a very short message indi-
cating which one failed.
The most common cause of system failures is hardware failure, which
can reflect itself in different ways. Here are the messages which
you are likely to encounter, with some hints as to causes. Left
unstated in all cases is the possibility that hardware or software
error produced the message in some unexpected way.
timeout table overflow
This really shouldn't be a panic, but until we fix up the data
structure involved, running out of entries causes a crash. If
this happens, you should make the timeout table bigger.
machine check %x: description
machine dependent machine-check information
We should describe machine checks, and will someday. For now,
ask someone who knows (like your friendly field service peo-
ple).
trap type %d, code=%d, pc=%x
A unexpected trap has occurred within the system; the trap
types are:
1 NMI trap
2 abort trap
3 floating point unit trap
4 illegal instruction trap
5 system call trap
6 divide by zero trap
7 flag trap
8 bpt instruction trap
Printed 11/16/83 1
CRASH(8) GENIX Programmer's Manual CRASH(8)
9 trace trap
10 undefined instruction trap
The favorite trap type in system crashes is trap type 9, indicating
a wild reference. The code is the referenced address, and the pc at
the time of the fault is printed. These problems tend to be easy to
track down if they are kernel bugs since the processor stops cold,
but random flakiness seems to cause this sometimes, e.g. we have
trapped with code 80000800 three times in six months as an instruc-
tion fetch went across this page boundary in the kernel but have
been unable to find any reason for this to have happened.
init died
The system initialization process has exited. This is bad
news, as no new users will then be able to log in. Rebooting
is the only fix, so the system just does it right away.
That completes the list of panic types you are likely to see.
When the system crashes it write (or at least attempts to write) a
image of the current memory into the back end of the primary swap
area. After the system is rebooted, the program savecore(8) runs
and preserves a copy of this core image and the current system in a
specified directory for later perusal. See savecore(8) for details.
To analyze a dump you should begin by running ps -alxk to print the
process table at the time of the crash. Use adb(1) to examine
/vmcore. The location dumpstack-80000000 is the bottom of a stack
onto which were pushed the stack pointer sp, PCBB (containing the
physical address of a u_area), MAPEN, IPL, and registers r13-r0 (in
that order). r13(fp) is the system frame pointer and the stack is
used in standard calls format. Use adb(1) to get a reverse calling
order. In most cases this procedure will give an idea of what is
wrong. A more complete discussion of system debugging is impossible
here. See, however, analyze(8) for some more hints.
SEE ALSO
analyze(8), reboot(8)
VAX 11/780 System Maintenance Guide for more information about
machine checks.
BUGS
There should be a better program than analyze(8) available which
prints out more of the system state symbolically after a crash to
lessen the tedious tasks involved in crash analysis.
Printed 11/16/83 2