rgviva

same

AppleACPIPlatform kext v1.3.6 does not solve the problem

Thanks for the ACPI Platform kext i will try it later today. I feel a bit uncomfortable installing 10.6.x kext on 10.9 but if it works then i'm good I also want to understand the problem if possible. I might attach a serial cable and do remote debug to see where the CPU is spending time. The AppleRTC patch im using is the last port of the second link, i actually created this patch perl -pi -e 's|\x41\x89\xd7\x41\x89\xf4|\xe9\xb8\x00\x00\x00\x90|;' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC In AppleRTC there is a cmos write routine, so i short circuit it to not touch cmos at all (e9 b8 is jmp to end of routine). As far as i could see in IDA, cmos writes are used to update the system clock and to wake up the system after some time period (alarm). I don't care about those features to the patch is good for me. Haven't had any CMOS errors after applying it.

Problem: my computer (Dell T5500) running 10.9 manages to go into sleep mode but when i press the power button to wake it up, it is "stuck" for 4-5 minutes and then finally it wakes up properly. Weird! Saw similar reports here: https://github.com/tkrotoff/ASUS-P5E3Premium-Hackintosh/issues/1 Setup details: Dell T5500, Dual Xeon X5560 - lspci attached LPC/RTC kexts loaded (RTC CMOS Reset problem fixed) NullCPU* kext removed Chameleon-2.2svn-r2266 c-states p-states enabled SMBios set to MacPro5,1 DSDT/Info attached 11/10/13 9:52:09.000 AM kernel[0]: Wake reason: VBTN (User) 11/10/13 9:56:19.000 AM kernel[0]: RTC: PowerByCalendarDate setting ignored 11/10/13 9:56:19.000 AM kernel[0]: Previous Sleep Cause: 5 11/10/13 9:56:19.000 AM kernel[0]: RTC: PowerByCalendarDate setting ignored 11/10/13 9:56:19.000 AM kernel[0]: USBF: 108.623 AppleUSBEHCI::CheckSleepCapability - controller will be unloaded across sleep 11/10/13 9:56:19.000 AM kernel[0]: USBF: 108.623 AppleUSBEHCI::CheckSleepCapability - controller will be unloaded across sleep 11/10/13 9:56:19.000 AM kernel[0]: The USB device HubDevice (Port 2 of Hub at 0x5d000000) may have caused a wake by being disconnected 11/10/13 9:56:19.174 AM WindowServer[92]: CGXDisplayDidWakeNotification [108779685774]: posting kCGSDisplayDidWake 11/10/13 9:56:19.174 AM WindowServer[92]: handle_will_sleep_auth_and_shield_windows: Reordering authw 0x7fa74a41c840(2004) (lock state: 3) 11/10/13 9:56:19.174 AM WindowServer[92]: handle_will_sleep_auth_and_shield_windows: err 0x0 11/10/13 9:56:19.000 AM kernel[0]: Auth result for: c8:60:00:e7:43:38 MAC AUTH succeeded 11/10/13 9:56:19.000 AM kernel[0]: AirPort: Link Up on en0 11/10/13 9:56:19.000 AM kernel[0]: en0: BSSID changed to c8:60:00:e7:43:38 11/10/13 9:56:19.919 AM configd[19]: LINKLOCAL en0: parent has no IP Note ~4 minutes between Wake reason and RTC messages... Any ideas? T5500.zip lspci.txt.zip