I am very happy to hear about your success and hope that your problems are solved for good.
However, I have a sadder story of my own to report.
After more than two weeks of absolutely no issues whatsoever with my new Crucial RAM I had a kernel panic. Then within 24 hours another panic followed that contained the following ominous lines in the log:
panic(cpu 6 caller 0xffffff800f4c4516): "
Possible memory corruption: pmap_pv_remove(0xffffff80520d8e78, 0x12222b000, 0x2d660, 0x1c00002d660066, 0xffffff83b6dc3bb4, 0xffffff83b6dc3ba8): pv not on hash, head: 0xffffff80520d8e78, 0x1363a3000"@/SourceCache/xnu/xnu-2422.90.20/osfmk/i386/pmap_internal.h:836
Backtrace (CPU 6), Frame : Return Address
0xffffff83b6dc39f0 : 0xffffff800f422fa9
0xffffff83b6dc3a70 : 0xffffff800f4c4516
0xffffff83b6dc3be0 : 0xffffff800f477587
0xffffff83b6dc3d50 : 0xffffff800f478fdf
0xffffff83b6dc3f20 : 0xffffff800f4dc26c
0xffffff83b6dc3fb0 : 0xffffff800f4f322b
As is widely reported in here, the kernel panics with problem RAM are totally random and impossible to induce. However, I created a Memtest86 EFI boot CD and booted to it. Usually when I run Memtest86 I get no errors on any of the RAM I've tried but have always just run it in the default single-CPU mode. This time I set it to multi-CPU Parallel mode.
I realized that not only does it run the tests much quicker (duh), I was seeing errors in a lot of the tests. So I removed the Crucial DIMMs and ran the test on just the Apple Elpida 2x8GB and went through an entire pass error-free. Just to make sure, i removed the Apple RAM and put in only the Crucial by itself and ran the test and the same errors were back.
So I have a replacement set on the way from Amazon, but the good news is I no longer have to wait for random kernel panics since a Memtest86 test in multi-CPU mode will be the first item on the agenda.
I urge anyone else having problems with their RAM to try Memtest86 in multi-CPU Parallel mode (
http://www.memtest86.com/download.htm)