BSD 4_3_Reno development

[unix-history] / usr / share / man / cat8 / vax / crash.0

CRASH(8V)		      1990			CRASH(8V)



N\bNA\bAM\bME\bE
     crash - what happens when the system crashes

D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
     This section explains what happens when the system crashes
     and (very briefly) how to 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 _\br_\be_\bb_\bo_\bo_\bt(8).  (If auto-reboot is disabled on the front
     panel 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 indicating which one failed.  In many
     instances, this will be the name of the routine which
     detected the error, or a two-word description of the incon-
     sistency.	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
     unexpected way.

     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/s\bsb\bbi\bin\bn/\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, _\bi_\bn_\bi_\bt(8).  The root filesystem is incorrect or
	  has been corrupted, or the mode or type of /sbin/init
	  forbids execution.




Printed 7/27/90               June				1






CRASH(8V)		      1990			CRASH(8V)



     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 device or an error in reading critical informa-
	  tion from a disk drive.  The offending disk should be
	  fixed if it is broken or unreliable.

     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 pro-
	  duced 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 normally occur.  A
	  filesystem check will normally correct the problem.

     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.

     K\bKS\bSP\bP n\bno\bot\bt v\bva\bal\bli\bid\bd
     S\bSB\bBI\bI f\bfa\bau\bul\blt\bt
     C\bCH\bHM\bM?\b? i\bin\bn k\bke\ber\brn\bne\bel\bl
	  These indicate either a serious bug in the system or,
	  more often, a glitch or failing hardware.  If SBI
	  faults recur, check out the hardware or call field ser-
	  vice.  If the other faults recur, there is likely a bug
	  somewhere in the system, although these can be caused
	  by a flakey processor.  Run processor microdiagnostics.

     m\bma\bac\bch\bhi\bin\bne\be c\bch\bhe\bec\bck\bk %\b%x\bx:\b:
	  _\bd_\be_\bs_\bc_\br_\bi_\bp_\bt_\bi_\bo_\bn

	_\bm_\ba_\bc_\bh_\bi_\bn_\be _\bd_\be_\bp_\be_\bn_\bd_\be_\bn_\bt _\bm_\ba_\bc_\bh_\bi_\bn_\be-_\bc_\bh_\be_\bc_\bk _\bi_\bn_\bf_\bo_\br_\bm_\ba_\bt_\bi_\bo_\bn
	  Machine checks are different on each type of CPU.  Most
	  of the internal processor registers are saved at the
	  time of the fault and are printed on the console.  For
	  most processors, there is one line that summarizes the
	  type of machine check.  Often, the nature of the prob-
	  lem is apparent from this messaage and/or the contents
	  of key registers.  The VAX Hardware Handbook should be
	  consulted, and, if necessary, your friendly field ser-
	  vice people should be informed of the problem.




Printed 7/27/90               June				2






CRASH(8V)		      1990			CRASH(8V)



     t\btr\bra\bap\bp t\bty\byp\bpe\be %\b%d\bd,\b, c\bco\bod\bde\be=\b=%\b%x\bx,\b, p\bpc\bc=\b=%\b%x\bx
	  A unexpected trap has occurred within the system; the
	  trap types are:

	  0    reserved addressing fault
	  1    privileged instruction fault
	  2    reserved operand fault
	  3    bpt instruction fault
	  4    xfc instruction fault
	  5    system call trap
	  6    arithmetic trap
	  7    ast delivery trap
	  8    segmentation fault
	  9    protection fault
	  10   trace trap
	  11   compatibility mode fault
	  12   page fault
	  13   page table fault

	  The favorite trap types in system crashes are trap
	  types 8 and 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 proces-
	  sor stops cold, but random flakiness seems to cause
	  this sometimes.  The debugger can be used to locate the
	  instruction and subroutine corresponding to the PC
	  value.  If that is insufficient to suggest the nature
	  of the problem, more detailed examination of the system
	  status at the time of the trap usually can produce an
	  explanation.

     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 net-
	  work buffers.  This usually indicates that buffers are
	  being lost, and rather than allow the system to slowly
	  degrade, it reboots immediately.  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 image of memory into the back end of the dump dev-
     ice, usually the same as the primary swap area.  After the
     system is rebooted, the program _\bs_\ba_\bv_\be_\bc_\bo_\br_\be(8) runs and



Printed 7/27/90               June				3






CRASH(8V)		      1990			CRASH(8V)



     preserves a copy of this core image and the current system
     in a specified directory for later perusal.  See _\bs_\ba_\bv_\be_\bc_\bo_\br_\be(8)
     for details.

     To analyze a dump you should begin by running _\ba_\bd_\bb(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.  A more complete discussion of
     system debugging is impossible here.  See, however, ``Using
     ADB to Debug the UNIX Kernel''.

S\bSE\bEE\bE A\bAL\bLS\bSO\bO
     adb(1), reboot(8)
     _\bV_\bA_\bX _\b1_\b1/_\b7_\b8_\b0 _\bS_\by_\bs_\bt_\be_\bm _\bM_\ba_\bi_\bn_\bt_\be_\bn_\ba_\bn_\bc_\be _\bG_\bu_\bi_\bd_\be and _\bV_\bA_\bX _\bH_\ba_\br_\bd_\bw_\ba_\br_\be _\bH_\ba_\bn_\bd_\b-
     _\bb_\bo_\bo_\bk for more information about machine checks.
     _\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





































Printed 7/27/90               June				4