Ok... I think we can rule out any loaded kernel extensions. At the time of the panic, the CPU's program counter (PC) is pretty low down in address space (i.e. around 0x00070314). That's pretty damn low. Extensions usually load much higher (at least, according to
kextstat on my system). You can start up Terminal yourself and type kextstat to see where your extensions are loaded, but I'd hazard a guess that none of them will be that low.
So the part of the system that's actually faulting here is pretty close to the metal -- kernel itself, iokit, nmi, mach, etc. Now these bits are pretty well tested, so panics this regular are unlikely to be
originally caused by these chunks of code. Now, the backtrace [EDIT: not 'backtrace'... I mean, 'exception chain'] in those logs is a little more interesting. There, the counter's much, much higher, indicating the user-mode app which made the call to the kernel code which led to the crash. Sadly, there's no way for us here to find which program was living at that memory address when the thing blew up. But, the fact that there's no kernel extensions implicated in the log leads me to surmise that:
- Possibly (somehow!) the bits of OS X which live real close to the metal have been corrupted. If you've managed that, I'll buy you a beer, because that's some feat. A quick Archive & Install restoration of OS X will fix this.
-or-
- There's a hardware fault. Since no kernel extensions were named, I can't be specific. For example, if the log mentioned
com.apple.iokit.IOUSBFamily, I'd point to a dodgy USB device (either internal or external). But with your logs, I'd first of all look to the RAM. It might just need re-seating in its slot(s), or it might actually be bad. There's always the possibility that there's something else defective (logic board, or even CPU).
So, try an Archive & Install first, then call AppleCare
Good luck!
