CRASH(8)             NetBSD/hp300 System Manager's Manual             CRASH(8)

NAME
     crash -- UNIX system failures

DESCRIPTION
     This section explains a bit about 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 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
     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 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
     unexpected way.

     iinit   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 alternative
             copy of the system binary or an alternative root filesystem can
             be used to bring up the system to investigate.

     Can't exec /sbin/init
             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 /sbin/init forbids execution.

     IO err in push
     hard IO err in swap
             The system encountered an error trying to write to the paging
             device or an error in reading critical information from a disk
             drive.  The offending disk should be fixed if it is broken or
             unreliable.

     realloccg: bad optim
     ialloc: dup alloc
     alloccgblk:cyl groups corrupted
     ialloccg: map corrupted
     free: freeing free block
     free: freeing free frag
     ifree: freeing free inode
     alloccg: map corrupted
             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-
             lem.

     timeout table overflow
             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.

     trap type %d, code = %x, v = %x
             An unexpected trap has occurred within the system; the trap types
             are:

                   0       bus error
                   1       address error
                   2       illegal instruction
                   3       divide by zero
                   4        chk instruction
                   5        trapv instruction
                   6       privileged instruction
                   7       trace trap
                   8       MMU fault
                   9       simulated software interrupt
                   10      format error
                   11      FP coprocessor fault
                   12      coprocessor fault
                   13      simulated AST

             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
             related 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 not 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:

                   <length> '@' <kernel VA>

             where both are in hex.  Following these values are a dump of the
             processor registers (hex).  Finally, is a dump of the stack
             (user/kernel) at the time of the offense.

     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.

     out of mbufs: map full
             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
     image 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
     details.

     To analyze a dump you should begin by running adb(1) with the -k 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 Using ADB to Debug
     the UNIX Kernel.

SEE ALSO
     adb(1), reboot(8)

     MC68020 32-bit Microprocessor User's Manual.

     Using ADB to Debug the UNIX Kernel.

     4.3BSD for the HP300.

HISTORY
     A crash man page appeared in Version 6 AT&T UNIX.

NetBSD 5.0_STABLE              January 12, 1994              NetBSD 5.0_STABLE
