Panic

Cause

A system panics and crashes when a program exercises an operating system bug. Although the crash might seem unfriendly to a user, the sudden stop actually safeguards the system and its data from further corruption.

Along with bringing the operating system to a stop, the panic routine copies the memory contents in use to a dump device, recording critical information about the current state of the CPU from which the panic routine was called.

Because the primary swap device is usually the default dump device, the primary swap device should be large enough to hold a complete image of memory. The system tries to reboot after the memory image is saved.

If the system does not reboot successfully, consider these possibilities:

1. Catastrophic hardware failure, such as faulty memory or a crashed disk;

2. Major kernel configuration faults, such as a buggy device driver;

3. Major kernel tuning errors, such as a too-large value for maxusers;

4. Data corruption, including corruption of the operating system files;

5. Manual intervention is needed, as when fsck(1M) expects answers to its queries.

Action

To find out why a system crashed, you can

1. Look in the /var/adm/message* log files;

Action

Of these methods, using savecore(1M) is the most informative. The savecore(1M) command transfers the system crash dump image generated by the panic routine from the dump device to a file system. The image can then be analyzed with a debugger such as adb(1).

See Also

Correctly setting up savecore(1M) and interpreting its results can be difficult. For more information about debugging system panics, refer to Panic! UNIX System Crash Dump Analysis by Chris Drake and Kimberley Brown (ISBN 0-13-149386-8).