How do I interpret a kernel panic log? (Here's one)

Question

How do I interpret a kernel panic log? (Here's one)

I apologize if there have been too many threads on kernel panics (and I'm adding to them). But Monday had my first one with my 2.5DP G5 POwerMac. I hadn't done anything unusual, only replying to an email, when the main screen greyed out, requesting that I restart using the power button.

Ten days ago, I installed Leopard. I also ran Disc Warrior, cleaned the preferences, etc. just to clean things up. I have the keyboard attached to the Belkin USB hub, instead of my usual direct connection to the box.

So, here is the log file as it reads. Can someone point out what the culprit may be? I have since run Apple Hardware Test, everything passed (running a total of 2.5GB Crucial memory). Thanks in advance.

Mon Mar 24 20:18:24 2008

Unresolved kernel trap(cpu 1): 0x300 - Data access
DAR=0x0000000000000004 PC=0x0000000000BB16BC
Latest crash info for cpu 1:
Exception state (sv=0x496c8a00)
PC=0x00BB16BC; MSR=0x00009030; DAR=0x00000004;
DSISR=0x42000000; LR=0x00BB1658; R1=0x48FFFD80; XCP=0x0000000C (0x300
- Data access)
Backtrace:
0x00BB1658 0x00BB197C 0x00BB1A90 0x000B05D4
Kernel loadable modules in backtrace (with dependencies):
com.apple.iokit.IOATABlockStorage(2.0.1)@0xba4000->0xbb6fff
dependency: com.apple.iokit.IOATAFamily(1.7.3f1)@0x8a6000
dependency: com.apple.iokit.IOStorageFamily(1.5.2)@0x7d3000
Proceeding back via exception chain:
Exception state (sv=0x496c8a00)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x56df6280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000;
DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

BSD process name corresponding to current thread: kernel_task

Mac OS version:
9C7010

Kernel version:
Darwin Kernel Version 9.2.2: Tue Mar 4 21:23:43 PST 2008;
root:xnu-1228.4.31~1/RELEASE_PPC
System model name: PowerMac7,3
panic(cpu 1 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 1:
Backtrace:
0x0009B478 0x0009BE1C 0x00029DD4 0x000AF210 0x000B2A78
Proceeding back via exception chain:
Exception state (sv=0x496c8a00)
PC=0x00BB16BC; MSR=0x00009030; DAR=0x00000004;
DSISR=0x42000000; LR=0x00BB1658; R1=0x48FFFD80; XCP=0x0000000C (0x300
- Data access)
Backtrace:
0x00BB1658 0x00BB197C 0x00BB1A90 0x000B05D4
Kernel loadable modules in backtrace (with dependencies):
com.apple.iokit.IOATABlockStorage(2.0.1)@0xba4000->0xbb6fff
dependency: com.apple.iokit.IOATAFamily(1.7.3f1)@0x8a6000
dependency: com.apple.iokit.IOStorageFamily(1.5.2)@0x7d3000
Exception state (sv=0x56df6280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000;
DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

BSD process name corresponding to current thread: kernel_task
|.8

Posted on Mar 26, 2008 6:44 AM

Reply

Answer 1

japamac

Level 7

24,400 points

Mar 26, 2008 7:30 AM in response to Chet Wisniewski

Hi Chet-

The first line after "backtrace" identifies the location, and describes the process involved at the time of the panic.
In this case, "com.apple.iokit.IOATABlockStorage" is indicated. This can be caused by a bad hard drive, internal or external, corrupt kernel in the OS BSD, or by a problem with the ATA controller on the logic board.
The panic occurred during data access "Unresolved kernel trap(cpu 1): 0x300 - Data access" which resulted in the CPU stumbling over some bad instruction occurring during the data access. "BSD process name corresponding to current thread: kernel_task" indicates the problem to be/have occurred at the root level of the system.

Determining whether the problem is hardware or software based, is the problem, and can take quite a bit of effort.
To troubleshoot, the AHT was a good start. Would recommend running Rember just to get a second opinion on the RAM.
Of course, you need to disconnect all external devices, except keyboard, mouse and monitor. If you use an external hard drive, definitely disconnect it, run for a while, and see if the panic occurs again. If panics still occur, you need to look at the internal drive.
Running the computer in Safe Mode, or in a new user account, are ways of confirming whether or not the problem is software based. If panics occur in Safe mode, hardware is more than likely the culprit. Same goes with a new user account.
Since the Leopard install is relatively new, and, I assume that you installed on the old, original hard drive in your Mac, it may be worth while to zero the drive (one pass) and reinstall the OS. Especially if you installed over Tiger, or previous OS version, there could be a bit or two on the hard drive that isn't right, raising the potential for kernel panic. That said, a drive, even zeroed, can cause problems if failing.

Since it has only happened once, you may just want to take a "wait and see" approach. If a panic occurs in the near future, note the log (well done) and begin the trouble shooting.

Resources:
Resolving Kernel Panics
12 Steps to isolate freezes/panics

Reply