Welcome to the MacNN Forums.

JasonRomney · Jan 7, 2006, 02:01 PM

I would be very grateful for advice from anyone who can spot a solution please to a severe kernel panic problem I am having. Here's the history. I'm have been getting persistent kernel panics on a G5 with 4GB of RAM, dual processor 2.5Ghz June 2004 model (+ firewire 800 PCI card and GeForce 6800 Ultra graphics card, all firewire drives unplugged for testing) since the end of 2005 when I started doing big encodes for the video iPod in MPEG4 and H.264. I get intermittent panics while doing various things. Examples of activities that trigger a panic include (mainly) encoding video, but also (just once) while copying a file and (again just once) while burning a DVD. The panic will occur during an encoding at apparently random points - sometimes it is half way through, sometimes it is right at the end. Sometimes I have the Activity Monitor going, sometimes I don't. I have run many diagnostic and repair utilities, including latest versions of Tech Tools, memtest, xbench, Disk Warrior and Disk Utility. I've repaired all permissions and disk problems (although the disks were in almost perfect shape to begin with and continue to show up without any errors). The whole suite of extended TechTool Pro 4.1.1 diagnostics reveals no problems at all with all hardware. I have disconnected all peripherals. I have completely reinstalled on a freshly formatted drive, a new install of Tiger, updated it all to the latest versions of all software, and only put on it the basic software I use for encoding (latest versions of ffmpeg 0.0.9u and MPEG Streamclip 1.5.1). But the panics persist.
Here's the log:

Thu Dec 29 17:52:01 2005
panic(cpu 1 caller 0x0009A920): mapping_tst_refmod: invalid physical page 05706CC0

Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x0009A920 0x0007B474 0x0007B790 0x000A9814
Proceeding back via exception chain:
Exception state (sv=0x01005280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Thu Dec 29 18:03:43 2005
panic(cpu 1 caller 0x0009A920): mapping_tst_refmod: invalid physical page 05706CC0

Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x0009A920 0x0007B474 0x0007B790 0x000A9814
Proceeding back via exception chain:
Exception state (sv=0x01005280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Thu Dec 29 22:25:25 2005

Unresolved kernel trap(cpu 1): 0x300 - Data access DAR=0x0000000000000004 PC=0x0000000000062E3C
Latest crash info for cpu 1:
Exception state (sv=0x54959C80)
PC=0x00062E3C; MSR=0x00009030; DAR=0x00000004; DSISR=0x42000000; LR=0x00062D8C; R1=0x44973DB0; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x00062D04 0x000A875C 0x000ABC80
backtrace terminated - frame not mapped or invalid: 0xBFFFEE40

Proceeding back via exception chain:
Exception state (sv=0x54959C80)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x60DA7780)
PC=0xFFFF8B2C; MSR=0x0200F030; DAR=0x010FC000; DSISR=0x42000000; LR=0x0024163C; R1=0xBFFFEE40; XCP=0x0000000C (0x300 - Data access)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
panic(cpu 1 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x000A8304 0x000ABC80
Proceeding back via exception chain:
Exception state (sv=0x54959C80)
PC=0x00062E3C; MSR=0x00009030; DAR=0x00000004; DSISR=0x42000000; LR=0x00062D8C; R1=0x44973DB0; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x00062D04 0x000A875C 0x000ABC80
backtrace terminated - frame not mapped or invalid: 0xBFFFEE40

Exception state (sv=0x60DA7780)
PC=0xFFFF8B2C; MSR=0x0200F030; DAR=0x010FC000; DSISR=0x42000000; LR=0x0024163C; R1=0xBFFFEE40; XCP=0x0000000C (0x300 - Data access)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC

*********

Fri Dec 30 06:59:48 2005

Unresolved kernel trap(cpu 1): 0x300 - Data access DAR=0x0000000000000010 PC=0x0000000000081828
Latest crash info for cpu 1:
Exception state (sv=0x5CA39780)
PC=0x00081828; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x0008180C; R1=0x4483BD30; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0002D3A4 0x0007B3B8 0x0007B790 0x000A9814
Proceeding back via exception chain:
Exception state (sv=0x5CA39780)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x01004000)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
panic(cpu 1 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x000A8304 0x000ABC80
Proceeding back via exception chain:
Exception state (sv=0x5CA39780)
PC=0x00081828; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x0008180C; R1=0x4483BD30; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0002D3A4 0x0007B3B8 0x0007B790 0x000A9814
Exception state (sv=0x01004000)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Fri Dec 30 16:42:41 2005

Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x0000000000000010 PC=0x0000000000081838
Latest crash info for cpu 0:
Exception state (sv=0x54957780)
PC=0x00081838; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x0008180C; R1=0x448A3B00; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0003F21C 0x0008221C 0x00075D98 0x00075758 0x0006B29C 0x0006B570
0x00057760 0x000291C0 0x000233AC 0x000ABFAC 0x00000000
backtrace terminated - frame not mapped or invalid: 0xF01FBA70

Proceeding back via exception chain:
Exception state (sv=0x54957780)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x5CA89A00)
PC=0x9000B208; MSR=0x0200D030; DAR=0x1D0B3000; DSISR=0x42000000; LR=0x9000B15C; R1=0xF01FBA70; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
panic(cpu 1 caller 0xFFFF0003): simple lock (0x003DD190) deadlock detection, pc=0x00081A40

Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x000A4FC8 0x00081A40 0x0007F778 0x0007D744 0x0007D4FC
0x002D5BF4 0x002D5EB4 0x002D4BC0 0x002D3FA8 0x00535A70 0x005309F0 0x00531308 0x0052DA4C
0x00AA9478 0x00AAA97C 0x0003C744 0x000A9814
Kernel loadable modules in backtrace (with dependencies):
com.apple.iokit.IOSCSIMultimediaCommandsDevice(1.4 .4)@0xaa0000
dependency: com.apple.iokit.IODVDStorageFamily(1.4)@0xa83000
dependency: com.apple.iokit.IOSCSIArchitectureModelFamily(1.4. 4)@0x529000
dependency: com.apple.iokit.IOStorageFamily(1.4)@0x4e2000
dependency: com.apple.iokit.IOSCSIBlockCommandsDevice(1.4.4)@0 xa8a000
dependency: com.apple.iokit.IOCDStorageFamily(1.4)@0xa79000
com.apple.iokit.IOSCSIArchitectureModelFamily(1.4. 4)@0x529000
Proceeding back via exception chain:
Exception state (sv=0x01003A00)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Fri Dec 30 19:44:52 2005

Unresolved kernel trap(cpu 1): 0x300 - Data access DAR=0x0000000000000010 PC=0x0000000000081838
Latest crash info for cpu 1:
Exception state (sv=0x5F13E500)
PC=0x00081838; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x0008180C; R1=0x448E38E0; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x989BE112
backtrace terminated - unaligned frame address: 0x61DCCC9E

Proceeding back via exception chain:
Exception state (sv=0x5F13E500)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x7456B280)
PC=0x9000606C; MSR=0x0200D030; DAR=0x00304000; DSISR=0x42000000; LR=0x90B279E8; R1=0xBFFFC0F0; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
panic(cpu 0 caller 0xFFFF0003): simple lock (0x003DD190) deadlock detection, pc=0x00081A40

Latest stack backtrace for cpu 0:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x000A4FC8 0x00081A40 0x000624C8 0x000A875C 0x000ABC80
Proceeding back via exception chain:
Exception state (sv=0x5F0C0280)
PC=0xFFFF8814; MSR=0x0000F030; DAR=0x00269000; DSISR=0x42000000; LR=0x90429560; R1=0xBFFEEAC0; XCP=0x0000000C (0x300 - Data access)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Fri Dec 30 21:23:21 2005

Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x0000000000000010 PC=0x0000000000081828
Latest crash info for cpu 0:
Exception state (sv=0x5CA89280)
PC=0x00081828; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x0008180C; R1=0x44843D30; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x00032954 0x0007B3B8 0x0007B790 0x000A9814
Proceeding back via exception chain:
Exception state (sv=0x5CA89280)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x01005280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
panic(cpu 0 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 0:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x000A8304 0x000ABC80
Proceeding back via exception chain:
Exception state (sv=0x5CA89280)
PC=0x00081828; MSR=0x00009030; DAR=0x00000010; DSISR=0x40000000; LR=0x0008180C; R1=0x44843D30; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x00032954 0x0007B3B8 0x0007B790 0x000A9814
Exception state (sv=0x01005280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Sat Dec 31 09:18:15 2005

Unresolved kernel trap(cpu 0): 0x300 - Data access DAR=0x0000000030988000 PC=0x0000000000081FA0
Latest crash info for cpu 0:
Exception state (sv=0x74909780)
PC=0x00081FA0; MSR=0x00009030; DAR=0x30988000; DSISR=0x40000000; LR=0x00081EA4; R1=0x448037C0; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0001C000 0x000821BC 0x0007CA60 0x00289150 0x000DD338 0x000DC7EC
0x00228B58 0x000FBD60 0x000F5338 0x0027D238 0x0027D060 0x002A9BF4 0x000ABE30 0xFA7B7037
backtrace terminated - frame not mapped or invalid: 0xF027CCB0

Proceeding back via exception chain:
Exception state (sv=0x74909780)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x7490AA00)
PC=0x90053AEC; MSR=0x0200F030; DAR=0x1F487000; DSISR=0x42000000; LR=0x90B51504; R1=0xF027CCB0; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
panic(cpu 0 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 0:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x000A8304 0x000ABC80
Proceeding back via exception chain:
Exception state (sv=0x74909780)
PC=0x00081FA0; MSR=0x00009030; DAR=0x30988000; DSISR=0x40000000; LR=0x00081EA4; R1=0x448037C0; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0001C000 0x000821BC 0x0007CA60 0x00289150 0x000DD338 0x000DC7EC
0x00228B58 0x000FBD60 0x000F5338 0x0027D238 0x0027D060 0x002A9BF4 0x000ABE30 0xFA7B7037
backtrace terminated - frame not mapped or invalid: 0xF027CCB0

Exception state (sv=0x7490AA00)
PC=0x90053AEC; MSR=0x0200F030; DAR=0x1F487000; DSISR=0x42000000; LR=0x90B51504; R1=0xF027CCB0; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Sun Jan 1 07:54:05 2006
panic(cpu 1 caller 0x00220FCC): hfs_vnop_reclaim: vp points to wrong cnode

Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x00220FCC 0x000FD734 0x000E5D9C 0x000E60AC 0x000E8508
0x000E7DE4 0x000E868C 0x00221500 0x002311B4 0x000F8FE4 0x0010D55C 0x0010D798 0x000FB140
0x000E20C8 0x000E1C5C 0x000F4B24 0x000ED008 0x000ED3C8 0x002A9BF4 0x000ABE30 0x09090909
Proceeding back via exception chain:
Exception state (sv=0x5CA8BA00)
PC=0x90001CEC; MSR=0x0200F030; DAR=0xE11FB000; DSISR=0x42000000; LR=0x90B24A38; R1=0xF0282DE0; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC

*********

Sun Jan 1 09:13:41 2006
panic(cpu 1 caller 0x00220FCC): hfs_vnop_reclaim: vp points to wrong cnode

Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x00220FCC 0x000FD734 0x000E5D9C 0x000E60AC 0x000E8508
0x000E7DE4 0x000E868C 0x00221500 0x002311B4 0x000F8FE4 0x0010D55C 0x0010D798 0x000FB140
0x000E20C8 0x000E1C5C 0x000F4B24 0x000ED008 0x000ED3C8 0x002A9BF4 0x000ABE30 0x09090909
Proceeding back via exception chain:
Exception state (sv=0x5CA8BA00)
PC=0x90001CEC; MSR=0x0200F030; DAR=0xE11FB000; DSISR=0x42000000; LR=0x90B24A38; R1=0xF0282DE0; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC

*********

Sun Jan 1 11:22:14 2006

Unresolved kernel trap(cpu 1): 0x300 - Data access DAR=0x00000000BA1CB004 PC=0x000000000007B12C
Latest crash info for cpu 1:
Exception state (sv=0x74C82500)
PC=0x0007B12C; MSR=0x00009030; DAR=0xBA1CB004; DSISR=0x02200000; LR=0x0007B0C0; R1=0x447F3D80; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x04311DB4 0x77C02000
backtrace terminated - unaligned frame address: 0x83DF00B8

Proceeding back via exception chain:
Exception state (sv=0x74C82500)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x01005280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
panic(cpu 1 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 1:
Backtrace:
0x04311A9C
backtrace terminated - unaligned frame address: 0x04311A18

Proceeding back via exception chain:
Exception state (sv=0x74C82500)
PC=0x0007B12C; MSR=0x00009030; DAR=0xBA1CB004; DSISR=0x02200000; LR=0x0007B0C0; R1=0x447F3D80; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x04311DB4 0x77C02000
backtrace terminated - unaligned frame address: 0x83DF00B8

Exception state (sv=0x01005280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********

Sun Jan 1 17:05:34 2006
panic(cpu 1 caller 0x0007CB10): need corner case for fictitious page
Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x0007CB10 0x00289150 0x000DF42C 0x000DBECC 0x000DC158
0x000DE494 0x000DDEF0 0x00228360 0x000FBC24 0x000F516C 0x0027CD4C 0x0027C9B8 0x002A9BF4
0x000ABE30 0x7275652F
Proceeding back via exception chain:
Exception state (sv=0x5CEFF500)
PC=0x9001422C; MSR=0x0200F030; DAR=0x005E3000; DSISR=0x42000000; LR=0x000168E0; R1=0xBFFFF330; XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC
*********
Other results can be seen in a picture at this location: http://netvideo.dreamhosters.com/PostRAMreseatPanic.jpg

memtestOSX showed this result:
Stuck Address : FAILURE: possible bad address line at offset 0x022d81ee.
Solid Bits : FAILURE: 0xffffffffffffbfff != 0xffffffffffffffff at offset 0x022d01ee.
Bit Flip : FAILURE: 0xffffffffffffbfff != 0xffffffffffffffff at offset 0x023dc1ee.
*** Address Test Failed *** One or more DIMM address lines are non-functional.
*** Memory Test Failed ***

When I retrieved the G5 from the Apple Certified Technician the verdict was: No fault detected. The special Apple Diagnostic Software ASD 2.5.7 showed all clean after an extended test. Yet when I got the machine home, I had another kernel panic while encoding from MPEG2 to H.264.
First, this is what the Apple Tech did:
1/ Removed DIMMS and, in order of removal, used an eraser to clean the gold connectors.
2/ Used an electronics vacuum with a small connector to remove dust from DIMM connectors.
3/ Removed, cleaned and re seated FireWire 800 card.
4/ Apple Hardware Test (AHT) was not used as it is a scaled down version of Apple Service Diagnostic (ASD)
5/ Booted into Open Firmware and performed the following
set-defaults
reset-screen
printenv
reset-nvram
reset-all
6/ No software (system or 3rd party) was updated in the diagnostic process.
Ram was replaced back in the slots that they came from. This was done to preserve the possibility of a DIMM not working with a particular slot that it was originally installed in.
The tech says the only step that could have performed but which he chose not to do, was to reseat the processor block. The tech felt this to be unnecessary.
When I retrieved the G5 and attempted a video encode in H.264, 1.5 hours later, a panic occurred which left the following in the panic log:
Sat Jan 7 20:02:36 2006
Unresolved kernel trap(cpu 1): 0x300 - Data access DAR=0x000000001BEF1004
PC=0x000000000007B12C
Latest crash info for cpu 1:
Exception state (sv=0x5C7BD780)
PC=0x0007B12C; MSR=0x00009030; DAR=0x1BEF1004; DSISR=0x02200000;
LR=0x0007B0C0; R1=0x447A3D80; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0007B0C0 0x0007B790 0x000A9814
Proceeding back via exception chain:
Exception state (sv=0x5C7BD780)
previously dumped as "Latest" state. skipping...
Exception state (sv=0x00FD4280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000;
LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-
792.6.22.obj~2/RELEASE_PPC
panic(cpu 1 caller 0xFFFF0003): 0x300 - Data access
Latest stack backtrace for cpu 1:
Backtrace:
0x00095698 0x00095BB0 0x0002683C 0x000A8304 0x000ABC80
Proceeding back via exception chain:
Exception state (sv=0x5C7BD780)
PC=0x0007B12C; MSR=0x00009030; DAR=0x1BEF1004; DSISR=0x02200000;
LR=0x0007B0C0; R1=0x447A3D80; XCP=0x0000000C (0x300 - Data access)
Backtrace:
0x0007B0C0 0x0007B790 0x000A9814
Exception state (sv=0x00FD4280)
PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000;
LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown)

Kernel version:
Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-
792.6.22.obj~2/RELEASE_PPC
*********

So what should I do now?

Best wishes and thanks in advance for anyone's thoughts on this,
Jason Romney
+61419372661

Detrius · Jan 7, 2006, 03:25 PM

Okay, the Apple Certified Technician you took your machine to is wrong. You have RAM problems. memtestOSX confirmed it. If he is relying on ASD as the definitive test of whether hardware is good or bad, he has a LOT to learn about being a technician (at least he didn't use TechTool Pro... ASD is really good, but you can't rely on any software that passes your hardware--only a failed status is reliable). I was an Apple Certified Technician for an Apple Authorized Repair Center for a couple of years myself until April of last year (now I'm a programmer).

Figuring out whether you have bad RAM or a bad RAM socket can be a lengthy procedure. Since memtestOSX has proved itself capable of finding your specific memory problem, that's the tool that should be used to verify whether you have bad RAM or a bad logic board.

Since memtestOSX doesn't tell you which module failed, figuring out what is causing the problem will likely take an excessive amount of time (I'm talking possibly days of just running tests, depending on the amount of RAM you have and the number of modules you have). I would start with just reseating your RAM modules where they are. Re-run memtest and see if you still get a failure. If not, then you fixed your problem (yes, I'm serious). If you still get a failure, you (or someone else) will need to go through all the modules and sockets and figure out what configurations cause failures. It's a puzzle to be solved.

If reseating the modules doesn't fix your problem, you have at least one bad socket or at least one bad module. It's possible to have multiple issues (I think three is the most I ever saw).

Good luck!

JasonRomney · Jan 8, 2006, 01:09 PM

Thanks for this reply Detrius. I have now extracted 4 of the 8 DIMMS and I am running MemtestOSX again. If the test comes back clean through 5 passes I will assume I have at least 4 good 512MB DIMMS in place. I will then add another pair so I have a total of 3GB installed and run MemtestOSX again. If that comes back showing a fault, I will assume it is with the DIMMS I just added. If that comes back clean, I will assume the fault lies in the last two DIMMS. I may run a test on those last two DIMMS on their own in that event. Does this seem like a reasonable strategy for diagnosing the problem to you?
Kind regards and thanks,
Jason Romney

Detrius · Jan 8, 2006, 03:15 PM

Originally Posted by JasonRomney

Thanks for this reply Detrius. I have now extracted 4 of the 8 DIMMS and I am running MemtestOSX again. If the test comes back clean through 5 passes I will assume I have at least 4 good 512MB DIMMS in place. I will then add another pair so I have a total of 3GB installed and run MemtestOSX again. If that comes back showing a fault, I will assume it is with the DIMMS I just added. If that comes back clean, I will assume the fault lies in the last two DIMMS. I may run a test on those last two DIMMS on their own in that event. Does this seem like a reasonable strategy for diagnosing the problem to you?
Kind regards and thanks,
Jason Romney

Actually, a failure when the third set is installed doesn't necessarily mean it's the modules that are bad--it could be the sockets. Therefore, you would have to try the modules in known good sockets (with nothing in the questionable sockets) to see if it's actually the modules. If you still get a failure here, at least one of the two modules is bad. If not, then you have suspect RAM sockets. You'll have to try your known-good RAM modules in the sockets to find that out.

There's also the theoretical possibility that the RAM modules only fail in those specific sockets, but nothing else fails in the sockets. In this case, you're still looking at a logic board issue.

Like I said, it's a rather lengthy procedure.

Detrius · Jan 8, 2006, 03:20 PM

One more thing, btw... though Apple Hardware Test is a scaled down version of Apple Service Diagnostics, sometimes AHT finds memory faults that ASD doesn't. Also, if either of these find the memory fault, they can tell you specifically which socket failed.

JasonRomney · Jan 9, 2006, 06:05 PM

Folks, I need to interpret results from my RAM testing and would value people's expert advice on this please. Here is data about the results of the testing.

Assume, for the sake of this explanation, that we number each of the 8 slots in the G5 from 1 to 8, with 1 being the closest to the floor when the G5 is stood up vertically, and 8 being the highest off the ground. That means the bottom group of 4 slots are labelled 1 (lowest) to 4 (highest) and the top group of 4 slots are labelled 5 (lowest of the top group) through to 8 (highest off the ground of the top group).

Let's also assume that the DIMMs in those 8 slots are labelled A to H, where A was the DIMM closest to the floor and H was the DIMM highest off the floor. Thus the DIMM pairs are D-E (in the innermost slots), C-F (moving one out from the innermost slots), B-G and A-H. I hope that is clear.

Now here are the results. For each test, I ran MemtestOSX in single user mode, each time with the command /Applications/memtest/metest all 5 -L

The first test was of all 8 DIMMS installed and it failed.

For the second test, I removed DIMMS A and B from slots 1 and 2, and G and H from slots 7 and 8, but left in all other DIMMS. The second test configuration failed.

For the third test, I left in only DIMMs D and E in slots 4 and 5 as the only DIMMS present. The test passed.

For the fourth test, I moved DIMMs C and F into slots 4 and 5 as the only DIMMS present. The test passed.

For the fifth test, I moved DIMMS D and E into slots 3 and 6 as the only DIMMS present. The test passed.

For the sixth test, I put back DIMMS C and F in slots 3 and 6, but had no other DIMMS present. The test passed.

At least as regards the DIMMS from slots 3 to 6, it seems at this point that individual DIMM pairs test OK when tested individually (as a pair on their own), even when moved to a different pair of slots, but that when DIMMs work in concert (as in test 2 above), they fail. This theory appears to be verified by tests 2-6.

Do you think this interpretation is valid? And more importantly, do you think this test data indicates a logic board fault rather than a RAM failure?

Kind regards and thanks in advance for any comments or advice on how to interpret this data,
Jason Romney

JasonRomney · Jan 9, 2006, 06:18 PM

I just tried a further test which failed. It was testing DIMMS C, D, E and F but changing their original order. In other words, originally these DIMMS were allocated as follows:
C to slot 3, D to slot 4, E to slot 5 and F to slot 6.
In this test, however, I put the DIMM pair C and F into slots 4 and 5. Then I put DIMM pair D and E into slots 3 and 6. The test failed.

JasonRomney · Jan 9, 2006, 11:30 PM

OK, a further test has provided more useful diagnostic data that I would welcome people's advice about interpreting. I took DIMMS A, B, G and H and inserted them into new slots thus: DIMM A was inserted in slot 3, DIMM B was inserted in slot 4, DIMM G was inserted in slot 5 and DIMM H was inserted in slot 6. This test passed.
Note that none of these DIMMs had been tested previously, except in the very first test when all the DIMMs (A to H) were tested at once, in slots 1 to 8. (see previously posting for explanation as to the 1-8 and A-H coding here).

I am now going to take out of the computer the DIMMS that have just passed this test (namely A, B, G and H) and assume these DIMMs are OK.

I will put back into the G5 now, the DIMMS that have tested faulty in various configurations, namely DIMMs C, D, E and F. But I will put them in new slots in a combination that has not been tested yet, namely: DIMM C in slot 1, DIMM D in slot 2, DIMM E in slot 7 and DIMM F in slot 8.

Best, Jason Romney

JasonRomney · Jan 10, 2006, 06:41 PM

Here is a summary of my recent testing. If anyone would interpret this data please, I'd be very grateful.

Explanatory assumptions:

Hardware: G5 with 4GB of RAM, dual processor 2.5Ghz June 2004 model, with two internal 250GB hard drives (+ firewire 800 PCI card and GeForce 6800 Ultra graphics card, but all external firewire drives unplugged for testing).

Memory: DIMMS are 8 sticks of 512MB memory from http://www.legendmemory.com/
Type of RAM: DDR SDRAM PC3200U-30330
RAM purchased from G5's original vendor (Apple vendor www.mymacaustralia.com.au). The RAM was not upgraded subsequently to original G5 purchase. All RAM sticks are from the same vendor (LegendMemory) and are of the same spec.

Terminology: Each of the 8 RAMM slots in the G5 are numbered from 1 to 8, with 1 being the closest to the floor when the G5 is stood up vertically, and 8 being the highest off the ground. That means the bottom group of 4 slots are labelled 1 (lowest) to 4 (highest) and the top group of 4 slots are labelled 5 (lowest of the top group) through to 8 (highest off the ground of the top group). The DIMMs in those 8 slots are labelled A to H, where, at the start of testing, A was the DIMM closest to the floor and H was the DIMM highest off the floor. Thus the DIMM pairs are D-E (in the innermost slots), C-F (moving one out from the innermost slots), B-G and A-H.

Diagnostic software: MemtestOSX (from http://www.memtestosx.org/) in single user mode, each time with the command /Applications/memtest/memtest all 5 -L

Test1:
Scope: all 8 DIMMS installed in slots 1 to 8, in the order that RAM came when the G5 was first purchased.
Result: fail
Detailed result:
Checkerboard : FAILURE: 0x5555555555555555 != 0x5555555555551555 at offset 0x0c60a9ea.
Bit Flip : FAILURE: 0xffffffffffffffff != 0xffffffffffffbfff at offset 0x084839ea.

Test2:
Scope: DIMMS A and B removed from slots 1 and 2, and DIMMS G and H removed from slots 7 and 8, leaving behind DIMMS C and D in slots 3 and 4 respectively, and DIMMS E and F in slots 5 and 6 respectively.
Result: fail
Detailed result:
Walking Ones : FAILURE: 0xffffffffffffbfff != 0xffffffffffffffff at offset 0x03c5b3ee.
Bit Flip : FAILURE: 0xfffffffffbffbfff != 0xfffffffffbffffff at offset 0x03c5b3ee.

Test3:
Scope: DIMMs D and E in slots 4 and 5 the only DIMMS present in the G5 (ie DIMM A removed from slot 1, DIMM B removed from slot 2, DIMM C removed from slot 3, DIMM F removed from slot 6 and DIMM G removed from slot 7 and DIMM H removed from slot 8).
Result: Pass

Test4:
Scope: DIMMs C and F moved into innermost slots (ie slots 4 and 5) and DIMMS C and F are the only DIMMS present in the G5.
Result: Pass

Test5:
Scope: DIMMS D and E moved into slots 3 and 6 and DIMMS D and E are the only DIMMS present in the G5.
Result: Pass

Test6:
Scope: DIMMS C and F tested alone in their original slots 3 and 6, but no other DIMMS present.
Result: Passed

Test7:
Scope: DIMMS C, D, E and F all present, but their ordering changed from their original slot distribution (ie DIMM C in slot 3, DIMM D in slot 4, DIMM E in slot 5 and DIMM F in slot 6) to a new distribution thus: DIMM pair C and F moved to slots 4 and 5 respectively and DIMM pair D and E moved to slots 3 and 6 respectively.
Result: Fail
Detailed result:
Compare SUB : FAILURE: 0xa49d8d6384cc66f5 != 0xa49d8d6384cc26f5 at offset 0x044bad5a.
Compare MUL : FAILURE: 0x6f47ab31d691fb82 != 0x78611e3214837b82 at offset 0x044bad5a.

Test8:
Scope: Extracted DIMM A from Slot 1 and reinserted DIMM A into Slot 3, Extracted DIMM B from Slot 2 and reinserted DIMM B into slot 4, Extracted DIMM G from slot 7 and reinserted DIMM G into slot 5, and extracted DIMM H from slot 8 and resinserted DIMM H into slot 6. All other DIMMS removed for test.
Result: Pass

Test9:
Scope: Inserted DIMM C in slot 1, DIMM D in slot 2, DIMM E in slot 7 and DIMM F in slot 8. No other DIMMS present.
Result: Pass

Test10:
Scope: Left DIMM C in slot 1, DIMM D in slot 2, DIMM E in slot 7 and DIMM F in slot 8 (ie the configuration in Test9 that passed), but additionally inserted DIMM A in slot 3, DIMM B in slot 4, DIMM G in slot 5 and DIMM H in slot 6.
Result: Fail
Detailed result:
Bit Flip : FAILURE: 0xffffffffff7fffff != 0xffffffffff7fdfff at offset 0x062f7894.
Bit Flip : FAILURE: 0xffffffffffffffff != 0xffffffffffffdfff at offset 0x02177894.

Kind regards and thanks,
Jason Romney

JasonRomney · Jan 12, 2006, 03:43 AM

For all those who have been kind enough to offer me assistance in this matter (and for others who may find themselves in a similar position at some stage) I submit this interpretation of the test results from the memory manufacturer's technical lead. It remains to be seen whether this fixes the problem but it does seem as if this is the right track. (If I don't post again, it means this was the correct diagnosis and the fix for the problem.)

The suggestion by the RAM engineer is that this problem is one of "loading AND compatability".

Firstly the RAM DIMMs I have are apparently OEM generic, sold to Techlynx. The RAM I have been using for the last year (with persistent, intermittent kernel panics) was designed for use in OEM Mac machines using the G4 CPU. The modules are apparently not specifically designed for my particular G5 machine, and therefore compatability is not guaranteed by the manufacturer. The correct part code for modules for my machine (a dual 2.5GHz G5) is apparently A3521xxx (where xxx is the size, 512 or 102 (1024mb) or 204 (2048mb)), whereas what I have been using is Techlynx A3968512 512MB PC-3200 DDR RAM. The latter (incorrect) RAM seems to work OK with normal OSX booting etc, but kernel panics from time to time on lengthy, processor intensive operations.

Also, although not clearly explained in the manuals, it is apparently the case that all motherboards have a limit to the number of modules they can support, in terms of power, bus length, timings, and so on. This is generally the same for all boards, barring a few conditions. The applicable rule in my G5's case is: Any board that uses unbuffered (unregistered) memory can only support a MAXIMUM OF 4 RANKS PER MEMORY CHANNEL.
(the specification for my particular G5 RAM, per the manual, is:
400 Mhz, PC 3200 DIMMs, 2.5 volt (V), 184-pin module, nonparity, no error-correcting codes (NECC), unbuffered (registered or buffered DDR SDRAM cannot be used)).

My board apparently has 2 channels, therefore in total it can only support 8 Ranks of memory.
Now, each of the modules I originally bought for my G5 consists of 2 ranks, meaning I have 16 ranks installed, using 8 modules.

So to solve this issue, I apparently need:
1) the correct parts for my particular G5 machine
2) 8 single ranked or 4 dual ranked modules maximum.

To stick with the 4GB total RAM target I've been working with hitherto, without exceeding my rank limits, the manufacturer recommended RAM called A3521204 (this is a kit of 2 x 1gb modules, so I would need 2 of this part code for 4 modules). This part code has apparently already been checked and tested by LEGEND in an appropriate MAC computer, and Legend says it has confirmed the part is supported.

I'm just so relieved, after so much troubleshooting time over the last year, to appear to be zeroing in on the solution. I want to thank everyone for their patient and generous assistance in helping me diagnose and fix this.

Kind regards,
Jason Romney
+614 19372661

JasonRomney · Jan 19, 2006, 03:57 PM

I'm happy to report that my Apple vendor swapped out my former RAM (8 sticks of 512MB) and replaced it with 4 sticks of 1GB, free of charge. I ran MemtestOSX and obtained a clean bill of health over 5 iterations of the test. Last night, I made a large encoding of an MPEG2 video file into the H.264 format, dual pass, without triggering a kernel panic. After a month of intensive diagnostics and analysis to get to the bottom of this problem - fingers crossed and breathe held - I feel it is likely that the grisly chapter is now closed. This is a valuable lesson for anyone with a high end Mac machine (well, if you can still call a dual 2.5Ghz processor G5 a high end machine now that the Intel Macs are coming on the market - sigh). The crucial take away is that both RAM compatibility AND loading must be taken into account and that this is an area that is not, in my view, sufficiently dealt with in the Apple manual. But I'm now happy with the new RAM (Hynex tier 1 DIMMS). Beware situations in which you have, say, eight modules of RAM stressing the memory controller (which must address 8 individual modules), potentially triggering a RAM ranking issue, and apparently, potentially stressing even the power supply (according to the RAM manufacturer's engineers).
Kind regards,
Jason Romney