Memory corrupted after longer sleep

[jginsbu]

Sorry to hear. I've now got an SSDT in place and will try to do some testing to see if that makes a difference over the weekend.

 

[jginsbu]

Adding an SSDT didn't solve the problem. Started testing last night: system made it through a number of shorter sleep cycles; left it to sleep overnight, system made it through without crashing, waking by itself approximately every two hours (despite darkwakes set to 0); let it go back to sleep for another 1.5 hours, at which point it crashed at the password screen upon waking the system from the keyboard.

Before it crashed I noticed a graphical glitch in the rendering of the blurred background image at the password screen -- since I'm using integrated graphics, this suggests memory corruption to me. Checking the system log, I see a cascade of errors, starting with the Finder and then the Window Server crashing; logging ends two seconds after wake, and the system reboots itself thereafter.

A few other notes on adding an SSDT…

Here's sample output from pmset -g live without an SSDT:

$pmset -g live
Active Profiles:
AC Power        -1*
Currently in use:
 hibernatemode        0
 womp                 0
 networkoversleep     0
 sleep                3
 Sleep On Power Button 1
 ttyskeepawake        1
 hibernatefile        /var/vm/sleepimage
 disksleep            10
 displaysleep         2

And here's the output with SSDT:

$pmset -g live
Active Profiles:
AC Power        -1*
Currently in use:
 standby              0
 Sleep On Power Button 1
 womp                 0
 hibernatefile        /var/vm/sleepimage
 darkwakes            0
 networkoversleep     0
 disksleep            10
 sleep                3
 autopoweroffdelay    14400
 hibernatemode        0
 autopoweroff         0
 ttyskeepawake        1
 displaysleep         2
 standbydelay         10800

Here's the Energy Saver pref pane without SSDT:


And here it is with the SSDT:


Notice that with the SSDT 'Computer Sleep' control is absent and 'Power Nap' toggle has appeared. Even though 'Computer Sleep' isn't in the pref pane, it can be controlled using pmset from the command line and the appears to work as expected.

Also, I noticed that adding an SSDT makes the 'Remote Disc' item appear under 'Devices' in the Finder sidebar.

I'm not sure which avenue to pursue next for testing.

 

[Ridley]

I've been having a similar issue.
MB: GA-Z97N Wifi
CPU: 4790K
RAM: 16 GB (2 x 8 ) Ballistic Sport DDR3 1600
No discrete GPU
3 TB Seagate Hard Drive

I installed using the Clover installation guide and the HD4600 config.plist. Whenever my computer goes to sleep, or shuts down, or the screens turn off, it will restart due to a CPU panic. I thought it was especially strange that it was doing it when just the screens turned off...

I was reading on here that people were having problems with CPU panics and multibeast with the 4790K
http://www.tonymacx86.com/mavericks...-panic-i7-4790k-z97n-working-i7-4790-a-6.html

I also experienced this. Its my first hackintosh and I would error out on CPU panics before getting to the desktop after having used multibeast. Clover has worked fine except for this issue i'm describing now.

To the post linked above, I tried disabling the turbo boost in the BIOS, but to no avail. Like some others have said though, and given the things people have tried so far, it looks like the common denominator might be Gigabyte MB and Devil's Canyon CPU?

 

[pista7]

Hi Guys,

I may have made some progress (though it might be to soon to be happy about it) - yesterday evening, I re-enabled the integrated graphics. During the night, the computer survived 5 dark wakes, and it still seems to be working perfectly after waking in the morning.

Just a tip to try out.

Note that (at least for me) after enabling the IGP, it takes significantly longer for the computer to boot (it seems stuck waiting fot the discrete graphics). I've had login screen 4-5 seconds after selecting the boot entry in Clover. Now it takes more like 30. But it obviously doesn't matter much to me, if it's a tradeoff I need to make to have stable sleep.

Oh, and as a good engineering practice (not!), I've also upgraded to 10.10.1 at the same time, so I don't really know which helped. I'll try to turn the IGP back off for the next night to see if it wasn't a bug in the kernel after all.

Best Regards,
Stefan

 

[jginsbu]

I may have made some progress (though it might be to soon to be happy about it) - yesterday evening, I re-enabled the integrated graphics. During the night, the computer survived 5 dark wakes, and it still seems to be working perfectly after waking in the morning.

FWIW, I've been running on integrated graphics all along. My last go at testing the system survived the darkwakes overnight but crashed later in the day.

I'm hoping that the 10.10.1 fixes for sleep/wake on Mac minis somehow benefit the problems we've been reporting here. Haven't had a chance to test under 10.10.1 myself yet, though.

 

[pista7]

Regarding the "hang" after enabling IGP - it was my fault, as I've had Graphics injection disabled in Clover. This resulted in the IGP being matched as legacy graphics by the kernel, which somehow had to time out before using the discrete card.

After enabling injection, the boot times are back to normal (with both graphics cards appearing in System Profiler) and an added bonus of having AirPlay Mirroring (and most likely QuickSync) available It seems that OS X is able to use the IGP even when it's not connected to a monitor.

I can't report on stability yet - no crash so far, but I haven't had time to use the system extensively.

 

[pista7]

So the system appears to be "more stable", which unfortunately doesn't mean completely stable. It still has various small problems after waking up, sometimes leading to a panic.

One more thing that helped - after enabling the IGP, the system started using it do decode videos, sometimes resulting in garbled green-ish blocks instead of an actual picture. I have tried different ig-platform-ids to no avail. Whan finally helped was setting the IGP memory in BIOS to 128MB. I have no idea why this setting is "magic" - at 512, the system simply rebooted when playing video, at other settings (both the default 64 and 256), the videos were "green" most of the time. At 128, it seems to work reliably all the time (at least so far), with AirPlay Mirroring is working as well.

 

[pista7]

Guys, can you please provide the following info regarding your builds?

1. Does your SATA controller register as Generic AHCI Controller? (You can check it in System profile, or even better, check for your driver class under SAT0 in IORegistryExplorer)
2. Do you get an "incorrect number of file hard links" error when checking your disk almost all the time, including immediately after fixing the disk in single user mode?

I've patched the Info.plist to register my SATA controller as an 8 Series, and it seems that both problems disappeared. I'm running stable since morning.

There might be something specific to intel's controllers, as the actual driver class for them (AppleintelPchSeriesAHCI) is different than the generic one (AppleAHCI). I have a theory that there is some power management problem in the generic driver. Yesterday, I managed to copy a disk file containing bit errors just after wake up. After purging the caches, the contents of the original file went back to normal again. Since I've proven to myself that my RAM is OK several times, it led me to take a closer look at the drive controller as the possible source for the bit flips.

 

[jginsbu]

1) Yes, vendor is listed as "Generic" (checked both ways).
2) No, I haven't seen that error when checking disks yet.

Thanks for continuing to work at this problem. I've been busy with other things and haven't been testing actively.

 

[pista7]

Hey jginsbu,

Try adding this to your Clover KextsToPatch and let me know if it helped:

			<dict>
				<key>Comment</key>
				<string>SATA Chipset</string>
				<key>Find</key>
				<string>pci8086,8c02</string>
				<key>InfoPlistPatch</key>
				<true/>
				<key>Name</key>
				<string>AppleAHCIPort</string>
				<key>Replace</key>
				<string>pci8086,8c82</string>
			</dict>

Note that you have to restart witout kext cache for the patch to be applied. The controller should then appear as an 8 Series if it works correctly. It could be changed to 9 easily via another kextpatch, but I don't really care about what it displays, just that it seems to work