This is what's known as a Kernel Panic, and it has been compared to the "Blue Screen of Death", which is familiar in certain Microsoft operating systems.
According to Apple's Knowledge Base article
, a kernel panic "is a type of error that occurs when the core (kernel) of an operating system receives an instruction in an unexpected format, or that it fails to handle properly. A kernel panic may also follow when the operating system is not able to recover from a different type of error. A kernel panic can be caused by damaged or incompatible software or, more rarely, damaged or incompatible hardware."
The so-called 'grey screen of death' was introduced in OS X 10.2 and indicates that a kernel panic has occurred, which is essentially an unrecoverable system crash that requires a reboot. To see what caused the kernel panic, launch Apple System Profiler (it's in /Applications/Utilities) and select the log tab at the top right of the window. The log will be very technical, but you should be able to figure out what caused the problem.
has kindly pointed out an Apple document
that explains in detail how to read and interpret the kernel panic log.Thanks to Johnny for the Apple System Profiler tip
also tells us a little more in-depth information as to how the kernel works:
In any operating system that allows for multiple processes to run in a time-shared fashion, there must be a supervisor program that is responsible for stopping one process and resuming another, sharing the CPU and I/O resources so that all of the processes "appear" to run simultaneously.
It would be disastrous if one of these user processes executed an invalid instruction and that led to the loss of control of the supervisor. To prevent this, and to allow the supervisor to always be able to regain control, the memory space that the supervisor program runs in is protected - it can only be accessed when the supervisor has control. This allows the supervisor to intercept program errors of user processes and shut them down. If a user program crashes (tries to execute an invalid instruction or branch to or reference a memory location that it does not own, for example), the hardware on the CPU chip will branch to a specified location in the supervisor program's code. From there, the supervisor can remove the user program that last had control of the CPU, and continue with the next process in the queue.
If, however, there is a flawed instruction IN THE SUPERVISOR CODE, there is no "Supreme Supervisor" waiting in the wings to restart the supervisor. You can show mathematically that if the supervisor is notified by the hardware of a bad instruction and finds out that the instruction is in the supervisor's own code, there is no possible way for the supervisor to return to a known state without starting the machine over from scratch.
In Mac OS X, the supervisor program is known as Mach, aka the "Mach Kernel". If Mach goes to investigate the hardware's notification of a program error, and discovers that the error occurred while Mach's own code was in control, it has to "give up" due to the fact that there is no known recovery method.
This "giving up" is called a kernel panic. All the kernel can do at this point is try to branch to the "give up" code, which in Mac OS X draws the kernel panic screen and tries to write the current contents of all of the CPU registers and stack values to a file, and then it just waits for the user to restart.
In a nutshell, kernel panic means the kernel crashed and since it is the last resort for recovering from invalid instructions, it gives up.
There should not be any kernel panics if 100% of the code in the kernel is correct; but this can never be proven for all possible combinations of hardware and software. At present, the kernel panics in Mac OS X usually have to do with a particular combination of hardware, or faulty hardware, which the kernel has not been written to handle correctly, and when that particular combination occurs, the kernel executes an invalid instruction and goes through the panic sequence one it realizes that.
Now if the kernel gets caught in an infinite loop, the hardware has no way of knowing this (again, you can prove this with pure math), and therefore it will never put up the kernel panic information. The only way around this problem is to use an external separate CPU whose sole function is to check the main CPU (or rather, have the main CPU "check in" with it) periodically to see if the main CPU is stuck in a loop. This separate CPU is called a "watchdog timer", as if it is not "fed" (updated) by the main CPU it will "bark" (declare a loop status and restart the main CPU). Of course, if the code in the watchdog timer is faulty and goes into a loop, then you need a second watchdog to watch the first watchdog, and so forth.
For more discussion on kernel panics in OS X, see here: »Can someone explain a Kernel Panic on the Mac?
by JJ edited by rjackson
last modified: 2005-10-30 12:44:58