dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
4438
share rss forum feed


SirSteve
Premium
join:2003-11-28
Woodbury, CT

4 edits

Can someone explain a Kernel Panic on the Mac?

First, I'm an EE with 34+ years experience. I had a Mac back in the IIci days but went back to a PC. Soon I'll be buying a PowerBook for my daughter at college. She has a nice Windows PC right now but wants a PowerBook for mobility. She's always liked the Mac too.

So tell me, what is this KP (Kernal Panic) I read about with OS-X? How does a non techie handle a KP? My daughter is not a technical person and gets along quite well with her PC--but the PC doesn't have things like KPs.



rjackson
Premium,VIP,MVM,Ex-Mod 2005-13
join:2002-04-02
Ringgold, GA
kudos:1

Re: Can someone explain a Kernal Panic on the Mac?

A kernel panic happens when the kernel receives an instruction it is unable to handle and cannot recover from. Usually all you can do to recover from a KP is to reboot.

»docs.info.apple.com/article.html···m=106227


ruud4

join:2001-11-02
New Haven, CT
reply to SirSteve

The equivalent of a kernel panic on windows is the blue screen (of death).



bbarrera
Premium,MVM
join:2000-10-23
Sacramento, CA
kudos:1
reply to SirSteve

said by SirSteve:

How does a non techie handle a KP? My daughter is not a technical person and gets along quite well with her PC--but the PC doesn't have things like KPs.
The Mac tells you to reboot when a KP happens, as shown in the link given by above. The same type of problem on a PC is referred to as "Blue Screen of Death" (BSOD).


Johnny
Fed Up. Bye.
Premium
join:2001-06-27
Atlanta, GA
kudos:2

2 recommendations

reply to SirSteve

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.



SirSteve
Premium
join:2003-11-28
Woodbury, CT

Re: Can someone explain a Kernel Panic on the Mac?

Thanks for all the replies.

I have to say, in the PC world when using Windows 98/Me the Blue Screen of Death was known to most everyone. However, with a fully patched XP/SP2 system, I have never seen the BSD or experienced a crash that required a restart.


ruud4

join:2001-11-02
New Haven, CT
reply to SirSteve

Kernel panics on the Mac are just as rare. The only time I've seen them was with one 10.2.x revision where you could trigger a bug in the filesystem code by renaming a directory in a very interesting way, and with the drivers for a USB-based ADSL modem. In general (and as mentioned above), kernel panics only happen with faulty hardware or buggy drivers (or a bug in the kernel itself).
--
bgp hints - Internet routing news, hints, and tips.



Bubba_T
Fast Faisil Strikes Again
Premium
join:2001-09-22
Columbus, IN
reply to Johnny

Re: Can someone explain a Kernal Panic on the Mac?

Wow!! Johnny, you're awesome!! Thanks for explaining. I've always wondered what a KP is, but never experienced one. So anyway, thanks again!!!



ICanDigIt

@aol.com
reply to Johnny


abuelsamid

join:2002-01-02
Ypsilanti, MI
reply to SirSteve

Re: Can someone explain a Kernel Panic on the Mac?

We haven't had a Kernel panic on the 2 macs in our house since 10.1, and that was after a power failure and restart that caused a file system corruption. A data backup and system restore corrected it never to be repeated.


russotto

join:2000-10-05
West Orange, NJ
reply to SirSteve

A watchdog timer is typically hardware, no code to screw up. But the Mac doesn't use one. If you get the kernel in an infinite loop, the system hangs solid.



badcat2

join:2000-10-18
Glastonbury, CT
reply to Johnny

Re: Can someone explain a Kernal Panic on the Mac?

Johnny, Excellent explanation of a kernel panic, thanks!!!

Chris



bobrk
You kids get offa my lawn
Premium
join:2000-02-02
San Jose, CA
Reviews:
·SONIC.NET
reply to SirSteve

Re: Can someone explain a Kernel Panic on the Mac?

I must say that I've never seen a BSD on my various XP work boxen, but they do get to a point where they just don't work right any more, lose speed, and beome unresonsive. I had one today where Outlook first started acting up and then wouldn't start again. I just rebooted to fix it.

I've been running Mac OS X on a Cube since the beta days and now on both a Cube and a G5, and I don't think I've ever seen a KP. Lameass programs (like Safari) crash all the time, but the box doesn't.
--
AntiWar.com | bobrk | The Blow Kings



rjackson
Premium,VIP,MVM,Ex-Mod 2005-13
join:2002-04-02
Ringgold, GA
kudos:1

1 recommendation

reply to ICanDigIt

Re: Can someone explain a Kernal Panic on the Mac?

said by ICanDigIt :

:)
(waves to DB)

»All things Macintosh »I got a black screen telling me I had to reboot in many languages, what was it?


BrushedTooth
Remember To Shop Smart Shop S Mart

join:2001-02-12
Westerville, OH
reply to bobrk

Re: Can someone explain a Kernel Panic on the Mac?

Didn't microsoft disable the bsod and basically does a force reboot?
--
AKA Its_Smee, I got bored with that name.



TheBobby
Premium
join:2003-07-27
UK

said by BrushedTooth:

Didn't microsoft disable the bsod and basically does a force reboot?
By default it does, but you can set it to display the BSOD and not reboot.
--
*Bobby*
Net Junkie


Spicolli

join:2002-08-03
Saint Paul, MN
reply to SirSteve

The BSOD's are not always a thing of the past. I have 2 friends fully patched virus free XP's that get them at least once a week. For contrast though I had a Windows ME machine with little patches, no firewall protection, and not only did I not get a blue screen, I also never rebooted my machine for weeks at a time. All my friends used to say my ME machine was the most stable they've seen. The ibook I am using right now gets kernel panics a lot when I am using my USB wireless adapter. So every system has bugs.



Johnny
Fed Up. Bye.
Premium
join:2001-06-27
Atlanta, GA
kudos:2
reply to TheBobby

said by TheBobby:

said by BrushedTooth:

Didn't microsoft disable the bsod and basically does a force reboot?
By default it does, but you can set it to display the BSOD and not reboot.
Theoretically it is better for the kernel to just stop, as the system is in an unknown state at this point and there is no guarantee that the restart code will work, or that it is even intact. Since the exception occurred while kernel code was running, it may have written to any number of unknown locations in the kernel, even overwriting valid kernel code, before it finally hit a location that was an invalid instruction and bombed. This is why Mac OS X writes the kernel panic data to VRAM and reads it back into a disk file after reboot, as there is no guarantee that the disk driver code is in a workable state after a panic.

Let's say that the original bug was a branch instruction that was supposed to branch to location 4000 in the kernel, but somehow it was set to branch to location 5000 (this branch was supposed to be for a rare condition and the QA testing never actually caused this branch to be tested). So what happens when it jumps to location 5000 is it encounters valid instructions for storing the contents of the registers at whatever location is in register 15. The problem is that register 15 does not contain the proper address, as the program did not get to location 5000 from the place it was expected to - it got there from the bad branch instruction. So it proceeds to store the 32 registers in the 128 bytes starting at the location in register 15, which just happens to point to 8 bytes ahead of where the program is executing now. Unfortunately for the kernel, the last 124 bytes that it stores overwrites the beginning of the subroutine that writes a buffer of data to a track and sector on the hard drive. That code is now replaced with random data. After the store, the program proceeds to the next instruction which is a load, which proceeds fine, and then it executes the 4 bytes that it just erroneously stored in the location 8 bytes ahead of where it was 2 instructions ago. That 4 bytes happens to not be a valid opcode for the instruction set, and the CPU raises an exception, sending the program to the "handle interrupt" location. That is where it discovers that it was itself that caused the exception and it calls a panic. Now if it tried at that point to save something to disk, it would be trying to execute the garbage that it stored there before, and the CPU would again raise an exception, and the kernel would again call a panic, and try to write to disk again, and so forth forever.