cristoff Posted January 5, 2017 Share Posted January 5, 2017 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 More sharing options...
MaLd0n Posted January 5, 2017 Share Posted January 5, 2017 up ur full clover folder DSDT.cristoff.zip Link to comment Share on other sites More sharing options...
cristoff Posted January 5, 2017 Author Share Posted January 5, 2017 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 More sharing options...
MaLd0n Posted January 6, 2017 Share Posted January 6, 2017 use this version https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/RehabMan-MaciASL-2016-0423.zip Link to comment Share on other sites More sharing options...
cristoff Posted January 6, 2017 Author Share Posted January 6, 2017 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: After: 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 More sharing options...
MaLd0n Posted January 6, 2017 Share Posted January 6, 2017 use ssdt post ur config.plist and kextstat(run in terminal) Link to comment Share on other sites More sharing options...
cristoff Posted January 7, 2017 Author Share Posted January 7, 2017 Please see original post for the kextstat and config.plist. I will run some tests with SSDT and get back to you. Link to comment Share on other sites More sharing options...
MaLd0n Posted January 7, 2017 Share Posted January 7, 2017 u can try without GenericUSBXHCI my experience with GenericUSBXHCI is not good, many problems Link to comment Share on other sites More sharing options...
cristoff Posted January 12, 2017 Author Share Posted January 12, 2017 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 More sharing options...
Recommended Posts