CRASH(8) BSD System Manager's Manual CRASH(8)
c
\bcr
\bra
\bas
\bsh
\bh - UNIX system failures
D
\bDE
\bES
\bSC
\bCR
\bRI
\bIP
\bPT
\bTI
\bIO
\bON
\bN
This section explains a bit about system crashes and (very briefly) how
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 in-
vokes an automatic reboot procedure as described in reboot(8). Unless
some unexpected inconsistency is encountered in the state of the file
systems due to hardware or software failure, the system will then resume
The system has a large number of internal consistency checks; if one of
these fails, then it will panic with a very short message indicating
which one failed. In many instances, this will be the name of the rou-
tine which detected the error, or a two-word description of the inconsis-
tency. A full understanding of most panic messages requires perusal of
the source code for the system.
The most common cause of system failures is hardware failure, which can
reflect itself in different ways. Here are the messages which are most
likely, with some hints as to causes. Left unstated in all cases is the
possibility that hardware or software error produced the message in some
i
\bii
\bin
\bni
\bit
\bt This cryptic panic message results from a failure to mount the
root filesystem during the bootstrap process. Either the root
filesystem has been corrupted, or the system is attempting to use
the wrong device as root filesystem. Usually, an alternate copy
of the system binary or an alternate root filesystem can be used
to bring up the system to investigate.
C
\bCa
\ban
\bn'
\b't
\bt e
\bex
\bxe
\bec
\bc /
\b/e
\bet
\btc
\bc/
\b/i
\bin
\bni
\bit
\bt
This is not a panic message, as reboots are likely to be futile.
Late in the bootstrap procedure, the system was unable to locate
and execute the initialization process, init(8). The root
filesystem is incorrect or has been corrupted, or the mode or
type of _
\b/_
\be_
\bt_
\bc_
\b/_
\bi_
\bn_
\bi_
\bt forbids execution.
I
\bIO
\bO e
\ber
\brr
\br i
\bin
\bn p
\bpu
\bus
\bsh
\bh
h
\bha
\bar
\brd
\bd I
\bIO
\bO e
\ber
\brr
\br i
\bin
\bn s
\bsw
\bwa
\bap
\bp
The system encountered an error trying to write to the paging de-
vice or an error in reading critical information from a disk
drive. The offending disk should be fixed if it is broken or un-
r
\bre
\bea
\bal
\bll
\blo
\boc
\bcc
\bcg
\bg:
\b: b
\bba
\bad
\bd o
\bop
\bpt
\bti
\bim
\bm
i
\bia
\bal
\bll
\blo
\boc
\bc:
\b: d
\bdu
\bup
\bp a
\bal
\bll
\blo
\boc
\bc
a
\bal
\bll
\blo
\boc
\bcc
\bcg
\bgb
\bbl
\blk
\bk:
\b:c
\bcy
\byl
\bl g
\bgr
\bro
\bou
\bup
\bps
\bs c
\bco
\bor
\brr
\bru
\bup
\bpt
\bte
\bed
\bd
i
\bia
\bal
\bll
\blo
\boc
\bcc
\bcg
\bg:
\b: m
\bma
\bap
\bp c
\bco
\bor
\brr
\bru
\bup
\bpt
\bte
\bed
\bd
f
\bfr
\bre
\bee
\be:
\b: f
\bfr
\bre
\bee
\bei
\bin
\bng
\bg f
\bfr
\bre
\bee
\be b
\bbl
\blo
\boc
\bck
\bk
f
\bfr
\bre
\bee
\be:
\b: f
\bfr
\bre
\bee
\bei
\bin
\bng
\bg f
\bfr
\bre
\bee
\be f
\bfr
\bra
\bag
\bg
i
\bif
\bfr
\bre
\bee
\be:
\b: f
\bfr
\bre
\bee
\bei
\bin
\bng
\bg f
\bfr
\bre
\bee
\be i
\bin
\bno
\bod
\bde
\be
a
\bal
\bll
\blo
\boc
\bcc
\bcg
\bg:
\b: m
\bma
\bap
\bp c
\bco
\bor
\brr
\bru
\bup
\bpt
\bte
\bed
\bd
These panic messages are among those that may be produced when
filesystem inconsistencies are detected. The problem generally
results from a failure to repair damaged filesystems after a
crash, hardware failures, or other condition that should not nor-
mally occur. A filesystem check will normally correct the prob-
t
\bti
\bim
\bme
\beo
\bou
\but
\bt t
\bta
\bab
\bbl
\ble
\be o
\bov
\bve
\ber
\brf
\bfl
\blo
\bow
\bw
This really shouldn't be a panic, but until the data structure
involved is made to be extensible, running out of entries causes
a crash. If this happens, make the timeout table bigger.
t
\btr
\bra
\bap
\bp t
\bty
\byp
\bpe
\be %
\b%d
\bd,
\b, c
\bco
\bod
\bde
\be =
\b= %
\b%x
\bx,
\b, v
\bv =
\b= %
\b%x
\bx
An unexpected trap has occurred within the system; the trap types
4 _
\bc_
\bh_
\bk instruction
5 _
\bt_
\br_
\ba_
\bp_
\bv instruction
9 simulated software interrupt
The favorite trap type in system crashes is trap type 8, indicat-
ing a wild reference. ``code'' (hex) is the concatenation of the
MMU status register (see <hp300/cpu.h>) in the high 16 bits and
the 68020 special status word (see the 68020 manual, page 6-17)
in the low 16. ``v'' (hex) is the virtual address which caused
the fault. Additionally, the kernel will dump about a screenful
of semi-useful information. ``pid'' (decimal) is the process id
of the process running at the time of the exception. Note that
if we panic in an interrupt routine, this process may not be re-
lated to the panic. ``ps'' (hex) is the 68020 processor status
register ``ps''. ``pc'' (hex) is the value of the program
counter saved on the hardware exception frame. It may _
\bn_
\bo_
\bt be the
PC of the instruction causing the fault. ``sfc'' and ``dfc''
(hex) are the 68020 source/destination function codes. They
should always be one. ``p0'' and ``p1'' are the VAX-like region
registers. They are of the form:
where both are in hex. Following these values are a dump of the
processor registers (hex). Finally, is a dump of the stack (us-
er/kernel) at the time of the offense.
i
\bin
\bni
\bit
\bt d
\bdi
\bie
\bed
\bd
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.
o
\bou
\but
\bt o
\bof
\bf m
\bmb
\bbu
\buf
\bfs
\bs:
\b: m
\bma
\bap
\bp f
\bfu
\bul
\bll
\bl
The network has exhausted its private page map for network
buffers. This usually indicates that buffers are being lost, and
rather than allow the system to slowly degrade, it reboots imme-
diately. The map may be made larger if necessary.
That completes the list of panic types you are likely to see.
When the system crashes it writes (or at least attempts to write) an im-
age of memory into the back end of the dump device, usually the same as
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
To analyze a dump you should begin by running adb(1) with the -
\b-k
\bk flag on
the system load image and core dump. If the core image is the result of
a panic, the panic message is printed. Normally the command ``$c'' will
provide a stack trace from the point of the crash and this will provide a
clue as to what went wrong. For more details consult _
\bU_
\bs_
\bi_
\bn_
\bg _
\bA_
\bD_
\bB _
\bt_
\bo _
\bD_
\be_
\bb_
\bu_
\bg
_
\bt_
\bh_
\be _
\bU_
\bN_
\bI_
\bX _
\bK_
\be_
\br_
\bn_
\be_
\bl.
S
\bSE
\bEE
\bE A
\bAL
\bLS
\bSO
\bO
_
\bM_
\bC_
\b6_
\b8_
\b0_
\b2_
\b0 _
\b3_
\b2_
\b-_
\bb_
\bi_
\bt _
\bM_
\bi_
\bc_
\br_
\bo_
\bp_
\br_
\bo_
\bc_
\be_
\bs_
\bs_
\bo_
\br _
\bU_
\bs_
\be_
\br_
\b'_
\bs _
\bM_
\ba_
\bn_
\bu_
\ba_
\bl.
_
\bU_
\bs_
\bi_
\bn_
\bg _
\bA_
\bD_
\bB _
\bt_
\bo _
\bD_
\be_
\bb_
\bu_
\bg _
\bt_
\bh_
\be _
\bU_
\bN_
\bI_
\bX _
\bK_
\be_
\br_
\bn_
\be_
\bl.
_
\b4_
\b._
\b3_
\bB_
\bS_
\bD _
\bf_
\bo_
\br _
\bt_
\bh_
\be _
\bH_
\bP_
\b3_
\b0_
\b0.
H
\bHI
\bIS
\bST
\bTO
\bOR
\bRY
\bY
A c
\bcr
\bra
\bas
\bsh
\bh man page appeared in Version 6 AT&T UNIX.
projects / unix-history / blob