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.
In addition to stopping the operating system, 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:
Catastrophic hardware failure, such as faulty memory or a crashed disk
Major kernel configuration faults, such as an unstable device driver
Major kernel-tuning errors, such as a too-large value for MAXUSERS
Data corruption, including corruption of the operating system files
Manual intervention needed, as when fsck(1M) expects answers to its queries
To find out why a system crashed, you can look in the /var/adm/message* log files.
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).
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).