OpenBSD manual page server

Causes of system failure

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 inconsistency. 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 (e.g., bad memory) 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 a hardware or software error produced the message in some unexpected way.

no init

This panic message indicates filesystem problems, and 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.

trap type %d, code=%x, pc=%x

A unexpected trap has occurred within the system; the trap types are machine dependent and can be found listed in /sys/arch/ARCH/include/trap.h.

The code is the referenced address, and the pc is the program counter at the time of the fault is printed. Hardware flakiness will sometimes generate this panic, but if the cause is a kernel bug, the kernel debugger ddb(4) can be used to locate the instruction and subroutine inside the kernel 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.

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 immediately. The map may be made larger if necessary.

That completes the list of panic types you are likely to see.

Analyzing a dump

When the system crashes it writes (or at least attempts to write) an image of memory, including the kernel image, onto the dump device. On reboot, the kernel image and memory image are separated and preserved in the directory /var/crash.

To analyze the kernel and memory images preserved as bsd.0 and bsd.0.core, you should run gdb(1), loading in the images with the following commands:

# gdb
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.6".
(gdb) file /var/crash/bsd.0
Reading symbols from /var/crash/bsd.0...(no debugging symbols found)...done.
(gdb) target kvm /var/crash/bsd.0.core

[Note that the “kvm” target is currently only supported by gdb(1) on some architectures.]

After this, you can use the where command to show trace of procedure calls that led to the crash.

For custom-built kernels, you should use bsd.gdb instead of bsd, thus allowing gdb(1) to show symbolic names for addresses and line numbers from the source.

Analyzing saved system images is sometimes called post-mortem debugging. There are a class of analysis tools designed to work on both live systems and saved images, most of them are linked with the kvm(3) library and share option flags to specify the kernel and memory image. These tools typically take the following flags:

-M core

Normally this core is an image produced by savecore(8) but it can be /dev/mem too, if you are looking at the live system.

-N system

Takes a kernel system image as an argument. This is where the symbolic information is gotten from, which means the image cannot be stripped. In some cases, using a bsd.gdb version of the kernel can assist even more.

The following commands understand these options: fstat(1), netstat(1), nfsstat(1), ps(1), w(1), dmesg(8), iostat(8), kgmon(8), pstat(8), trpt(8), vmstat(8) and many others. There are exceptions, however. For instance, ipcs(1) has renamed the -M argument to be -C instead.

Examples of use:

# ps -N /var/crash/bsd.0 -M /var/crash/bsd.0.core -O paddr

The -O paddr option prints each process' struct proc address. This is very useful information if you are analyzing process contexts in gdb(1).

# vmstat -N /var/crash/bsd.0 -M /var/crash/bsd.0.core -m

This analyzes memory allocations at the time of the crash. Perhaps some resource was starving the system?

Analyzing a live kernel

Like the tools mentioned above, gdb(1) can be used to analyze a live system as well. This can be accomplished by not specifying a crash dump when selecting the “kvm” target:

(gdb) target kvm

It is possible to inspect processes that entered the kernel by specifying a process' struct proc address to the kvm proc command:

(gdb) kvm proc 0xd69dada0
#0  0xd0355d91 in sleep_finish (sls=0x0, do_sleep=0)
    at ../../../../kern/kern_synch.c:217
217                     mi_switch();

After this, the where command will show a trace of procedure calls, right back to where the selected process entered the kernel.