You are hereBlogs / R. Tyler Ballance's blog / Baby, I'll Panic Your Kernel Anytime
Baby, I'll Panic Your Kernel Anytime
I've been experiencing a kernel panic for the past couple weeks, sporadically, but I've finally come up with a reliable set of reproduction steps (for my set up anyways). I have a nagging feeling it has something to do with the Parallels Kernel Extensions (specifically the pseudo-networking devices).
The basics of my kernel panic are as follows, for purposes of demonstration, let's pretend Mac[0] is the machine you feel like kernel panicing, and Mac[1] is some other machine sitting around causing trouble:
- On Mac[0] enable "Personal File Sharing" (i.e. turn on Apple File Sharing)
- Using Mac[1], mount an AFP share from Mac[0].
- Transfer a large file (ISO, DMG, pr0n.mp4) from Mac[0] to Mac[1].
- Unmount the shared volume on Mac[1]
- Watch Mac[0] go grey like this.
I've been able to reproduce this at the login screen for Mac[0], all the way up to full interactivity (running iTunes, Xcode, etc). In my office, Mac[0] is a 20" intel iMac, whereas Mac[1] is a 12" PowerBook G4. If I had more machines to test with, I'm sure I'd be able to reproduce it there as well. I find it very unlikely that the Apple drivers are kernel panicing my box (see crash logs at end of post), as Apple's IOKit drivers seem to be very solid, so I'm guessing that it is related to the Parallels kernel extensions (.kext). A brief look at kextstat(8) returns this:
Regardless of whether or not Parallels is running, to ensure I don't come off as a Parallels-basher (even if I really am), VMWare leaves kernel extensions loaded when VMWare Fusion isn't running as well:
Anyways, back on topic. Given the inherently cryptic crash logs that a kernel panic will leave behind (if any), it's hard to truly tell what is causing the panic. As much as I like to fantasize about becoming an über 1337 kernel haxx0r, I simply haven't the time to whip out a firewire cable, and use Mac[1] as a debugging console to reproduce and crash my main workstation (Mac[0]).
As a software developer however, I'm a bit annoyed that these virtualization applications (Parallels, VMWare) are leaving KEXTs loaded into kernel space even when they're not running, leaving the door wide open to crashes like this one. Unfortunately, a kernel is only as strong as it's weakest link/kext, if one of the KEXTs crash in the spectacular fashion in which they normally do, they can bring down an entire system, possibly leaving a lone developer in central Texas with no other options than to crack open a beer shortly after lunch.
My G4 iMac gives me this grey screen after playing WoW for about an hour. I'll notice the graphics starting to go bad, and then all of the sudden my machine will quit responding, and then the grey screen will pop up. This has been very annoying for me. My first G4 iMac was giving me this grey screen without having WoW installed on it, so I wiped the hard drive and sold it on eBay, praying that the next owner was a 12 year old who would never experience it. I bought another iMac after that and it worked great until my hubby introduced me to World of Warcraft and I decided I had to install it on my iMac. I finally bought a new MacBook this past semester with my student loan money, and cleaned up the iMac and gave it to my computer-iliterate dad. He decided he hates Macs because they don't look and act like Windoze, so I got it back this last week.
Now I'm wondering what to do with my iMac should it start producing this grey screen again for me.
I'm going to school for CS, but all they really teach you in college is how to work on Windoze, so I'm a little lost...
With much (much) less knowledge of what exactly was going on, I found myself shooting similar trouble on my own Mac. I was amazed to find that two Parallels extensions (ConnectUSB & Pvsnet) survived both detailed manual uninstall instructions, as well as an uninstall script that shipped with a recent version of the software. This just seems wrong...
Having been harassed by erratic hard systems hangs for a couple weeks now, it's going to be days before I'm sure that I've actually solved the problem by getting rid of these kexts. But I'm bettin' I did!
Since virtualization solutions need to work directly with the hardware on most operating systems (there aren't any that I know of that provice the necessary APIs to user-space), there isn't much alternative to loading kernel code at boot time.
Rather than prompt for admin credentials each and every time you boot up a virtual machine, most virtualization software installs kernel code that handles the raw access to the hardware via a device that only setuid root binaries or otherwise specially privileged binaries can speak to.
The only other alternative would be for the software to prompt for admin credentials each and every time a VM was booted, which I think you can appreciate would be really obnoxious.
That being said, any panic bug is nasty and you should report it to VMware's support folks as well as Parallels', to determine what's going on.
If you have a Boot Camp virtual machine (which is what I guess most Mac people have), you still have to enter credentials every time that vm is started. So I wouldn't mind having the kexts unloaded on quit as well...
- nevyn