Chapter 20: System Crashes and Panics

One of the nice things about FreeBSD is its stability; the only Blue Screen of Death is a screensaver. In fact, it was almost a year before I realized that a FreeBSD machine could crash for reasons other than bad hardware.

FreeBSD can crash, or panic, but it allows you to recover from a panic fairly easily, so don't, er, panic. You can even connect to the console remotely when the system is completely locked up and nonresponsive, and force a reboot. FreeBSD provides the tools you need to discover exactly what happened, and gives you extensive debugging information about the panic. (Even if you don't know what to do with this information, you can submit a problem report and discuss the issue with the FreeBSD development team.)

What Causes Panics?

When does a system panic? Well, panicking is a choice that the kernel makes. If the system reaches a condition that it doesn't know how to handle, or if it fails its own internal consistency checks, it will panic.

If you're using FreeBSD as a desktop, you can panic it by doing a variety of things, most of which are hardware related. For example, in older FreeBSDs, you could panic a laptop by pulling out certain PCMCIA cards without shutting the card down first. (That's, fortunately, no longer the case.) Now, to panic a system, you pretty much have to do something wrong while logged in as root (or be running−current).

It's much more difficult to panic a server. Panics generally occur only if you have configured your kernel improperly, if you exhaust your system resources, or if you've tickled a previously unknown FreeBSD bug. The first two are pretty straightforward to fix, and are discussed in Chapters 4 and 18. The last is the most disturbing.

FreeBSD is complex, and not even its royal−blood lineage or open−source development process can protect it from bugs. (Some people argue that no software is bug−free.) Fortunately, that heritage and development process give you the information to debug FreeBSD yourself, and the tools to provide the information necessary for other people to debug it. You might begin with a cryptic error code, but you'll quickly learn that it means something to someone.

Note If you're not a programmer, don't worry. By preparing your system to debug panics, you'll help someone else to fix the problem. Hopefully, you'll never need to debug your system, but if you do, you'll be glad you have it set up properly!

What Does a Panic Look Like?

When a system panics, it stops running all programs. Instead of the usual console messages, the console displays a message much like this one:

...............................................................................................

Fatal trap 12: page fault while in kernel mode

fault virtual address =

0x80c0153a

fault code / supervisor write, page not present instruction pointer = 0x8:0xc015aa84

stack	pointer	=	0x10:0xc7377e7c
frame	pointer	=	0x10:0xc7377e80

452