Q: iMac G4 Kernel Panic

Klaus1 wrote:

 

Many kernel panics are RAM related. Could be that your 512 stick is either not seated properly or is unsuited for your G5 - check with OWC.

 

I checked those things--it is seated properly and is the correct one for this machine.

In addition, I still get a kernel panic when running memtest without the 512 stick in the machine. So if that indicates a RAM issue, it means the problem is with the internal 256 stick--in the user inaccessible spot.

I've never disassembled a lampshade iMac before, but I understand it's a pain. My question at this point is is it a good idea to disassemble the machine in order to replace the internal RAM and see if that's the problem?

But thanks, I'll go through the articles.

Thanks!

I found two guides for replacing the PRAM battery. Neither of them is exactly my model, but I think it should be similar. (I have a 15-inch iMac G4, 800 MHz).

iMac G4 15" 700 MHz EMC 1873 PRAM Battery Replacement

iMac G4 17" 800 MHz EMC 1936 Battery Replacement

First, do these guides look safe to use for my model? Second, won't this disassembly give me access to the internal RAM slot anyway?

Finally, in the meantime, I've confirmed that I do not have any third party kernel extensions installed by using this tip.

Please let me know your thoughts, thanks.

Ok. Yeah that guide actually requires removing the internal RAM to get to the PRAM battery. So replacing the PRAM battery isn't any easier than replacing the RAM.

Which brings me back to my original question--is replacing the internal RAM a good idea at this point or am I too likely to break something/should try something else first?

Here's the log of the most recent kernel panic, in case it means anything to anyone:

Fri Mar 21 23:59:10 2014

Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x00000000E704A1F5 PC=0x00000000000A9B8C

Latest crash info for cpu 0:

   Exception state (sv=0x370B2280)

      PC=0x000A9B8C; MSR=0x00003030; DAR=0xE704A1F5; DSISR=0x42000000; LR=0x000A9B88; R1=0xFC14FC21; XCP=0x0000000C (0x300 - Data access)

      Backtrace:

         backtrace terminated - unaligned frame address: 0xFC14FC21

Proceeding back via exception chain:

   Exception state (sv=0x370B2280)

      previously dumped as "Latest" state. skipping...

Kernel version:

Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC

panic(cpu 0 caller 0xFFFF0003): copyin/out has no recovery point

Latest stack backtrace for cpu 0:

      Backtrace:

         0x000954F8 0x00095A10 0x00026898 0x000A8204 0x000ABB80

Proceeding back via exception chain:

   Exception state (sv=0x370B2280)

      PC=0x000A9B8C; MSR=0x00003030; DAR=0xE704A1F5; DSISR=0x42000000; LR=0x000A9B88; R1=0xFC14FC21; XCP=0x0000000C (0x300 - Data access)

      Backtrace:

         backtrace terminated - unaligned frame address: 0xFC14FC21

Kernel version:

Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC

Another update: I can also trigger a kernel panic by running memtest from the terminal while booted in Safe Mode.

Ok, thanks, and thanks for the link. I guess I'll be taking this thing apart.

I guess PRAM batteries are pretty cheap--maybe as long as I'm going in there to replace the RAM I should replace the PRAM battery too?

I replaced the RAM and PRAM battery with those in the links above, and I had confirmed with OWC when I bought them that they are the correct ones. However, after the replacement, the kernel panics have gotten successively worse--it now panics immediately upon starting up, even if I'm trying to boot in safe mode or from an install disc.

Thoughts?

Thanks...

Something may have been seated wrong when I posted the above because I took it apart and seated everything again and it did a little better after that--I could boot into safe mode. It was still panicking though.

I also ran into an inability to repair or verify permissions from disk utility, but I was able to repair from the terminal with sudo diskutil.

I would generally be able to get a little further after a kernel panic if I did a PRAM reset before booting rather than just rebooting immediately. Not sure what that means.

I've also tried booting with the new RAM but the old PRAM battery (so the only combination I haven't tried is new PRAM battery, old RAM).

I've also booted without the user-accessible RAM installed, so it's not that.

Also note that I didn't use thermal paste when reattaching the base plate after installing the RAM and PRAM battery--not sure if overheating could cause a panic.

So finally I thought it might be a software issue, so I tried erasing the disk and doing a clean install of 10.4. But it kept hanging during the install, so I rebooted, and started zeroing out the disk from the install disc. It kernel panicked while zeroing out.

Thoughts? Does that most recent kernel panic indicate that it's not a software problem? And if I've ruled out RAM, PRAM battery, software, what's left?

Thanks...

A further update:

At least part of the problem seems to have been the use of a non-apple keyboard and mouse. I've switched those out now, and so far no kernel panic.

However, I have erased the hard drive so I can't boot from it.

I mentioned above that when zeroing out the disk while booted from an install disc, it would previously trigger a kernel panic. Now no kernel panic, but when I try to zero out the disc it just quits out of Disk Utility.

Additionally when I try to install it gets to "Installing Essentials" and then says "There Was an Error..."

So, I have another iMac G4 (this one is 700 MHz) which is in good shape. Using that as the host computer, I started the 800 MHz (problem) iMac in Target Disk Mode. It mounts, but only stays there for about 30 seconds (long enough to erase and verify the disk in Disk Utility, but not long enough to zero out the drive) before it shuts down.

So, that's got to be a hard drive problem, right?

I'd really appreciate feedback--if it's the hard drive, what I think I would do next is swap out the hard drive from the 700 MHz into the 800 MHz and see if that works.