Your transcript just looks plain weird. It looks like
it's comparing 64-bit values written and read and
they are miles different.
0x1b1b1b1b != 0x1a1a1a1a is kinda sensible but fatal,
while
0x00000001 != 0xfffffff5 is total nonsense.
There's no way your system could survive with that
level of error.
Neither memtest nor rember talk about testing the ECC
though. It would be good to know whether there is any
way of detecting the ECC status in those modules.
72-bit modules can correct one bit error (over the 8
bytes) and detect two. If we could see results of the
ECC activity it could give a heads up on the
likelihood that a RAM was about to fall over.
Actually I would hope the Mac would have some way of
knowing if the ECC is detecting errors and warning
the user.
Mac Pro
2.66/1G/890/SD/BT Mac OS X (10.4.7)
Somehow I feel the same way, this looks weird. The RAM works fine under realtime use, ripping DVD, encoding DVD, Firefox, Database and other open apps. No ECC errors are logged in ASP it says OK under all installed RAM and no Kernel Panics.
I ran Apple Diagnostics and no hicups, flawless fast and no slow down in speed as noted on other RAM hangs in at 667.
So I am keeping it.
I am going by what ASP says and Apple Diagnostics, all ok.
Thanks!
William
PS going on 24 hours no problems. Also, ASP does show EEC errors beside any RAM presenting them...
