NAME

crash − what happens when the system crashes

DESCRIPTION

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 the kernel was compiled with the debugger, the debugger is entered before the dump.  A “go iar+2” continues the dump and reboots. 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 operation.

The system has several internal-consistency checks; if one of these fails, the system panics, giving a brief message indicating which one failed. 

The most common cause of system failures is hardware failure, which shows itself in different ways.  The messages you are likely to encounter, along with some hints as to cause, are given below.  (Left unstated in all cases is the possibility that hardware or software error produced the message in some unexpected way.) 

I/O err in push

hard I/O err in swap
The system encountered an error trying to write to the paging device or in reading critical information from a disk drive. Fix the disk if it is broken or unreliable.

timeout table overflow
This really shouldn’t be a panic, but until the data structure involved has been fixed, running out of entries causes a crash.  If this happens, make the timeout table bigger.

trap

kernel trap not tlb

kernel trap
These indicate either a serious bug in the system or, more often, a glitch or failing hardware.

init died
The system-initialization process exited, blocking additional users from logging in.  Rebooting is the only fix, so the system just does it right away.

When the system crashes, it writes, or at least attempts to write, an image of 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).

To analyze a dump, begin by running adb(1) with the −k flag on the core dump. 

SEE ALSO

adb(1), analyze(8), reboot(8), savecore(8)
IBM RT PC Problem Determination Guide, SA23-1040, for more about hardware failures
“Using ADB to Debug the Kernel”, in the 4.3BSD UNIX System Manager’s Manual
 

PRPQs 5799-WZQ/5799-PFF: IBM/4.3  —  July 1987