Jump to content

need help to get Wakeup from Sleep working on MSI-Z68A-GD55(G3) ?


cristoff
 Share

9 posts in this topic

Recommended Posts

I got Sierra working on my spec and it's pretty wicked. However, I have been trying to get Wakeup working for the last 2 weeks and I think I am running out of ideas for a quick test. 

 

It takes a bit (like 30 seconds) to put computer to sleep. After that, when i press power on, instead of the Wakeup, Hackintosh just panics and restart follows.

 

What I got to after having done:

- the usual SSDT patch with ./ssdtPRGen.sh, 

- AICPMPatch

- trying few DSDT patches for other boards on the same chipset

- installing Kernel Development KIt

 

is a very interesting kernel panic report (credit goes to KDK I think):

*** Panic Report ***
panic(cpu 0 caller 0xffffff800a656f32): "/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.31.2/osfmk/kern/sched_prim.c:2687 Assertion failed: processor->last_dispatch >= self->last_made_runnable_time : " "Non-monotonic time? dispatch at 0xcddf7ba51, runnable at 0xd49d45978"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.31.2/osfmk/kern/sched_prim.c:2687

without KDK, it would panic like this:

panic(cpu 2 caller 0xffffff800996f6cf): initproc exited  -- exit reason namespace 2 subcode 0x8 description: none

Now, I am pretty sure it must be due to lack of a proper RTC and/or HPET patches for the board, but MSI-Z68A-GD55 is not a very common piece of hardware for what we are trying to do. I just could not source right set of patches. I am pretty sure if got through these 900 pages of ACPI spec I will get it to work but it is likely my hair goes grey before I get to the end of that book. In the meantime if somebody somewhere has some idea what patches to apply, your help will be appreciated. My DSDTs extract attached. I should have also mentioned HPET is enabled in BIOS.

dsdt.zip

kextstat.txt

config.plist.txt

Link to comment
Share on other sites

Thank you for the response. Appreciate your help and the DSDT, however it does not seem to be picked up during boot.

 

Also, getting strange behaviour when opening decompiled DSDT in MACIASL on Hackintosh - MACIASL just quits with this in /var/log/system.log

Jan  5 23:26:36 cristoffs-iMac com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.IDECacheDeleteAppExtension.544): Path not allowed in target domain: type = pid, path = /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Applications/Xcode.app/Contents/PlugIns/IDECacheDeleteAppExtension.appex
Jan  5 23:26:36 cristoffs-iMac com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.IDECacheDeleteAppExtension.544): Path not allowed in target domain: type = pid, path = /Applications/Xcode.app/Contents/Frameworks/DFRSupportKit.framework/Versions/A/XPCServices/IDETouchBarSimulatorService.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Applications/Xcode.app/Contents/PlugIns/IDECacheDeleteAppExtension.appex
Jan  5 23:26:41 cristoffs-iMac logd[53]: _handle_cache_delete_with_urgency(0x7fc19b721590, 3, 0)
Jan  5 23:26:45 cristoffs-iMac MaciASL[541]: assertion failed: 16C67: libxpc.dylib + 74307 [65E41BB6-EBD5-3D93-B0BE-B190CEE4DD93]: 0x89

Does it look I am missing some xcode extension?

 

Could you post the patches you applied too?

Link to comment
Share on other sites

I got it disassembled and loaded to MaciASL in the end. I will surely try to compare it against generic DSDT to learn something new. It contains patches worth noting. If you think explaining the patches will not take much time, please do. Thank you.

 

In the meantime, booting with new DSDT does not help with Wakeup from Sleep. Sadly it ends up in the same kernel panic about non monotonic time. What I have also noticed was a slight change in Power Management for the worse. However I did not regenerate SSDT after installing new DSDT - not sure if that is required as ssdtPRGen.sh does not seems to depend on it.

 

Before:

2vwwsk8.png

 

 

After:

11j3qyh.jpg

 

Also if you feel like having another shot at DSDT, please do. Otherwise, I think I will try debugging ACPI with Rehabman's kext and seeing what's going on with the kernel after wakeup. There must be something preventing setting real time clock after wakeup at least that's where my thinking goes.

Link to comment
Share on other sites

None of the suggestions helped. Removing GenericUSBXHCI, new DSDTs, nada. Seems no one else in the world had this problem. Not surprising.

 

All I know is this assertion in the kernel fails and the latency calculated on the next line is supposed to be positive.

assertf(processor->last_dispatch >= self->last_made_runnable_time, "Non-monotonic time? dispatch at 0x%llx, runnable at 0x%llx", processor->last_dispatch, self->last_made_runnable_time);
latency = processor->last_dispatch - self->last_made_runnable_time;

If somebody is well versed in the kernel code maybe they give a hint as to what is the cause of it. I have been trying to join the dots but cannot figure it out. Maybe HPET state does not get set after waking up from sleep, properly? But how to asses if the theory is right? 

Link to comment
Share on other sites

 Share

×
×
  • Create New...