i7-4930K - Asus Rampage IV Extreme - 32GB RAM - GTX 770 4GB [Success!!]

[frontend-dev]

I still think you should pull 1/2 your ram and test. Then test the other 1/2 just to eliminate that from the equation.

Hmm frankly, am not too eager to fiddle with my hardware again as I just replaced the mobo. Anyways, I have done another MemTest (UEFI Version) overnight and now RAM was tested for almost 24 hours in total, with no errors. Also tested in OS X (using rember) for some hours. And as I also shuffled RAM when replacing the mobo so I think I have tested every memory stick and area. Those panics are - in my opinion - far to specific and reproducable to be related to RAM.

Did these KPs start right after a OS update? Was there new software of any kind installed around the time they started?

Yeah, as I recall , it started after upgrading to 10.11 some months ago. And the problem still happens with a completely fresh install, but it does not seem to happen with a fresh 10.10 install. So apparently it has nothing to do with 3rd party software, but something with changes from 10.10 to 10.11. Of course its strange that I seem to be the only one having this specific problems.

 

[shilohh]

Do you know if they started at a specific version number (10.11.2 or 10.11.3)?

The most notable change for 10.11 is what we need for USB 2 to work.

I have some acpi updates coming. Most notably, I have figured out how to give HPET the IRQs it wants via ssdt which means we can have full functionality without patching the HPET device in the DSDT. With this update I will take us completely off of DSDT patching. Also I've done some work to the ssdt patch for USB 2. All of this is beta and I haven't had a chance to test much as I had to leave town again. If you want I'll send you the files but you won't want to use them with any of your old ones.

 

[thenightflyer]

@shilohh
What model of DDR3 are you using with your Rampage Extreme Black Edition?

 

[shilohh]

@shilohh
What model of DDR3 are you using with your Rampage Extreme Black Edition?

You can find it in my profile but here you go: RAM = 64GB (8x8GB) G.Skill F3-2133C9-8GZH

 

[frontend-dev]

Do you know if they started at a specific version number (10.11.2 or 10.11.3)?

Yeah I only started with El Capitan at Version 10.11.3

I have some acpi updates coming. Most notably, I have figured out how to give HPET the IRQs it wants via ssdt which means we can have full functionality without patching the HPET device in the DSDT. With this update I will take us completely off of DSDT patching. Also I've done some work to the ssdt patch for USB 2. All of this is beta and I haven't had a chance to test much as I had to leave town again. If you want I'll send you the files but you won't want to use them with any of your old ones.

So, IRQ patch using SSDT only? Wow, thought that was not possible. Yeah sure why not, you can send the files to me for testing.

Btw I have found out a bit more about my problem. So I have already tried a lot of RAM tests including rember (memTest frontend running in OS X) with no problems. Now I did something I did not do before and started a RAM test with Rember after sleeping. And guess what? I got a KP only 1 minute later and could also repeat this, while without sleeping it ran for hours without any problem.

Could this be a symptom of defective RAM? Or - even worse - a problem with the memory controller? Still very strange bc it only happens after sleep (and apparently only in 10.11, not in Win and not in 10.10) - but would explain why I could run UEFI Memtest for a very long time without any problems.

So yeah I think I have to do the DIMM swap test I fear. I also got a new type of KP then: "vm_compressor_pager_put: out of range". I then disabled memory compression (boot-arg: vm_compressor=1) and Rember did not crash when trying to replicate it, but I got some other KPs later on, so I dont think thats a reliable solution.

So no matter where it comes from, it seems that sleep corrupts my memory and / or some stuff like the kernel page maps. Therefore the endless "page fault errors" in launchd I ususally get.

 

[frontend-dev]

Well, I did the DIMM swap test and the results were even more strange. First I removed 4 DIMMs and tested, and the problem (almost) went away. I.e. I still had one "type 14=page fault" KP in about 20 tests (usually it would have been 19-20 KPs). This time with the umount process (usually its launchd).

OK, I thought it might be a bad DIMM. But: then I swapped the 4 remaining DIMMS with the 4 I just took out, and this time the problem went away as well, with no KPs in about 20 tests. And I really filled up the remaining 32GB, so that I had swapping and memory compression as well. Lastly I inserted all DIMMs again and the problem immediatly reappeared on the first test.

So, WTF? Is this RAM, is this the CPU memory controller having problems? OS X 10.11? Or even Clover?

Still, this only happens when:

• I am running on 10.11
• I do sleep before testing
• Mostly on subsequent restart / shutdown after waking
• I have all 8 DIMMs installed (well, apart from the single KP I had with only 4)

Any ideas? I really could need some help!

 

[shilohh]

So it does sound like a hardware fault (but not for sure) and as you mentioned, it could be a weak IMC or a bad stick of RAM. 64GB puts much more stress on the IMC than 32GB so it would make sense that the issue appears more often with all slots populated, even if it is just 1 bad stick. FYI, your vcore and vccsa voltages could still cause this if they are too low. Even if 1 stick of ram is twitchy, upping your voltages may make it stable. If your CPU's IMC is weak, it could require higher than "optimized default" voltage even to run at stock frequencies. As to why it acts up in 10.11 vs 10.10, I'd bet that Apple changed the way that paging and virtual ram are handled in 10.11. Might even have something to do with lack of ECC.

I'd start by seeing if the AppleTyMCEDriver is loading and if so, try deleting it. Test.

Next I'd see if I could eliminate the issue by bringing up the voltages that effect the IMC while leaving the CPU and ram at stock frequencies. I'd start with vcore and vccsa at 1.3v and I wouldn't go higher than 1.4v. Be sure to monitor temps and not to let the CPU go much higher than 85c while testing. You won't want to run them that high 24/7 but just for eliminating voltage and IMC as the culprit.

If it can't be eliminated with voltage, I'd try swapping RAM sticks (with the 4 that you had in that duplicated the problem installed) 1 at time with a known good sticks from the other batch (the 4 that you had in when you couldn't duplicate the problem) to see if you can pin point which stick is weakest.

 

[ivanski123]

When you install new hardware (2port Inateck USB card or any other), after creating DSDT in Clover (F4 press) do i have to run AutoDSDT.app

thanx

 

[shilohh]

When you install new hardware (2port Inateck USB card or any other), after creating DSDT in Clover (F4 press) do i have to run AutoDSDT.app

thanx

Yes. Then verify that the creation date of EFI/CLOVER/ACPI/patched/DSDT.aml is today. If it has a older creation date, delete it and run AutoDSDT again.

 

[frontend-dev]

I'd start by seeing if the AppleTyMCEDriver is loading and if so, try deleting it. Test.

That wasnt loaded.

Next I'd see if I could eliminate the issue by bringing up the voltages that effect the IMC while leaving the CPU and ram at stock frequencies. I'd start with vcore and vccsa at 1.3v

That did not help anything. At first try it worked (but could be a coincidence since I can reproduce the KPs in "only" about 95% of all cases) but then the problem was back, I even got a KP directly after waking up. Upping vccsa alone also did not work, in that case I even had multiple(!) KPs at shutdown, something which I never experienced before.

Well, so the IMC is not the culprit? Or something else I could check?