Vlada. Posted May 7, 2011 Share Posted May 7, 2011 Indeed… I have the same problem… Foxconn P35A motherboard, fully patched with ALC888 fix and PEGP for NVIDIA GTX275 graphics. In 10.6.7 everything works fine, but in Lion I can't enable graphics via DSDT patch (only NVEnabler64.kext works), also I was noticed that computer restart/shutdown properly, but enters in sleep a bit different… somehow more sudden and with a louder switch off... just pa-pap and that’s it… After proper wake and restart I'm having CMOS checksum bad report, or other words CMOS reset… I think that it’s not boot loader, because I had the same situation with XPC and Chameleon 2 RC5 rev752, so… probably it’s necessary to make certain changes inside DSDT for Lion, but the question is which and where? However, I can tell you one thing… Changing IO length for Device (RTC) from 2 on 4 or 8 is definitively not the solution… Link to comment Share on other sites More sharing options...
blackosx Posted May 7, 2011 Share Posted May 7, 2011 Related? Could be, but I don't have an eSATA drive to test with. I've been thinking, is there anyway to read the contents of CMOS from our hacks when booted in to OS X? This way we can capture it before entering sleep, then after to see what's changed or see if the checksum has changed, it might help? hmm... I've been reading and found this forum topic with a post to some assembler code, and the .COM executable for reading CMOS but it's for DOS. I might try to install a Windows VM from Lion and see if it works.... EDIT: Well I've tested this from both 10.6 where the CMOS doesn't get reset after reboot when having woken from sleep and again from 10.7 where I do get the CMOS reset after reboot when having woken from sleep. Differences between 10.6 and 10.7 (Values are Hex) Before entering sleep: Offset 10.6 10.7 00 47 24 02 28 20 0C 00 00 40 47 24 42 20 20 After waking from sleep: Offset 10.6 10.7 00 13 29 02 02 21 0C 40 40 40 13 29 42 02 21 Here's a collated image showing all four of the dumps from the Windows WM. What does this show? well I'm not really sure, but it might be food for thought for someone to build upon. UPDATE: Looking again I see the 00-3F is the data block and 40-7F is a duplicate of the first.? Nope, This is not right as otherwise, when offset 0C is changed, 4C should also be changed. I'm thinking the offset's 00 and 02 are the time, with 00 being seconds and 02 being minutes, so I guess these can be ignored which just leaves offset 0C which flips between 00 before sleep and 40 and after sleep. But these are the same for both 10.6 and 10.7 so the problem can't be there. Therefore, if these CMOS dumps are to be trusted, then maybe CMOS is changed by a different process in 10.7? (That can't be as OS X won't know about CMOS?) before reboot / shutdown depending on whether sleep has been used or not? UPDATE: Now I'm confused as booting in to 10.7 again and trying the same method shows offset 0C already set at 40 before entering sleep? I've also found a couple of other DOS tools, CMOSGET and CMOSPUT to read and write CMOS which I'll play with and I've also found a useful post showing what the various bytes are used for. So 00-0F is the RTC and 0C is a Status Register C... LATEST: Sorry for above ramblings as I was just reporting what I found as I went along. To further my understanding about the bytes read: 00-0D = RTC This can be split down in to the following: (Note I haven't included some of the bytes) 00 = Seconds 02 = Minutes 04 = Hours 06 = Day of the week 07 = Date of month 08 = Month 09 = Year 0A = Status Register A Set to 26 (00100110) which means: • Current time is not being set and ready to be read. • System is using 32.768Khz time base frequency • Bank 0 of CMOS RAM is accessed through RTC data register. • System initialised for the divider output frequency. 0B = Status Register B Set to 02 (00000010) which means: • The hour byte is set to 24 hour mode. 0C = Status Register C Set to 00 (00000000) when first read • Means nothing to report. Set to 40 (01000000) when read for a second time and after which means: • PF Flag=1 (A periodic interrupt has occurred). 0D = Status Register D Set to 80 (10000000) which means: • Valid RAM = 1. So contents of RAM are good. So to summise at this point: This all looks normal and doesn't really help here. Something is changing the CMOS data somehow? References found and used: CMOS Registers CMOS RAM Bank 0 More CMOS info at OS Dev Link to comment Share on other sites More sharing options...
rayap Posted May 8, 2011 Author Share Posted May 8, 2011 Another thing that happens is the ethernet is disabled after wake. Had to replug, ifconfig down/up does not work. Link to comment Share on other sites More sharing options...
Detrich Posted May 9, 2011 Share Posted May 9, 2011 I'm pretty sure, the problem is chameleon. Link to comment Share on other sites More sharing options...
blackosx Posted May 9, 2011 Share Posted May 9, 2011 I'm pretty sure, the problem is chameleon. Nope. I'm pretty sure the problem is there when booting from XPC , [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url] and Clover also. Another thing that happens is the ethernet is disabled after wake. Had to replug, ifconfig down/up does not work. Networking is fine here when waking from sleep. I don't have any issue with how the system runs when waking from sleep, just the CMOS checksum error when restarting. Link to comment Share on other sites More sharing options...
allenwkk Posted May 9, 2011 Share Posted May 9, 2011 I agree the CMOS reset problem is from the OS... same problem either boot from XPS or Chameleon for me. also, changed from Habitation mode 0 or 1 does not have any effect to the reset problem. Link to comment Share on other sites More sharing options...
blackosx Posted May 9, 2011 Share Posted May 9, 2011 Unless all bootloaders are not doing something then it's more likely an ACPI issue, but the question is what exactly..? Can we get a list of mobo brands that are experiencing this problem? So far here we have reports from: Asus (stefano.85, allenwkk) EVGA (iLeopod) Foxconn (Vlada.) Gigabtye (rayap, Maxetto, Javimdq, blackosx, edgar87, kjellamund, MaLd0n) MSI (stellarola) bossob reported no issue but has failed to come back with any details of hardware etc. Link to comment Share on other sites More sharing options...
Goron Posted May 9, 2011 Share Posted May 9, 2011 Unless all bootloaders are not doing something then it's more likely an ACPI issue, but the question is what exactly..? Can we get a list of mobo brands that are experiencing this problem? So far here we have reports from: Asus (stefano.85, allenwkk) EVGA (iLeopod) Foxconn (Vlada.) Gigabtye (rayap, Maxetto, Javimdq, blackosx, edgar87, kjellamund, MaLd0n) MSI (stellarola) bossob reported no issue but has failed to come back with any details of hardware etc. Got this issue with sys in sig. System SEEMS to sleep properly, but when waking up, i´m confronted with a black screen; after cold boot BIOS is reset to defaults ... DSDT fully working with S3 in SL ... just in case Link to comment Share on other sites More sharing options...
stefano.85 Posted May 9, 2011 Share Posted May 9, 2011 Got this issue with sys in sig. System SEEMS to sleep properly, but when waking up, i´m confronted with a black screen; after cold boot BIOS is reset to defaults ... DSDT fully working with S3 in SL ... just in case I've EXACTLY the same symptoms here as i've mentioned before but i've noticed one strange thing... in snow leopard auto-sleep never worked (always needed auto-script sleep "rip3lan"), instead in lion it works vanilla.... unfortunately then i have those problem with cmos ecc... i don't know if this can be usefull, if any expert coder/programmer wants our dsdt to troubleshoot i'm always available. Regards and keep the great work you all did so far. like always...apologize for english. Stefano Link to comment Share on other sites More sharing options...
rayap Posted May 10, 2011 Author Share Posted May 10, 2011 Unless all bootloaders are not doing something then it's more likely an ACPI issue, but the question is what exactly..? Can we get a list of mobo brands that are experiencing this problem? So far here we have reports from: Also if we post the kernel.log extract we can learn something from each other's setup. From kernel.log May 10 12:07:27 Rays-Mac-Pro kernel[0]: IOPMrootDomain: client 0xffffff7f80ba4e7c returned 120000000 for kIOMessageSystemWillSleep May 10 12:07:27 Rays-Mac-Pro kernel[0]: May 10 12:08:33 Rays-Mac-Pro kernel[0]: Wake reason: EHC2 May 10 12:08:33 Rays-Mac-Pro kernel[0]: The USB device Keyboard Hub (Port 2 of Hub at 0xfa000000) may have caused a wake by issuing a remote wakeup (2) May 10 12:08:33 Rays-Mac-Pro kernel[0]: The USB device Apple Keyboard (Port 2 of Hub at 0xfa200000) may have caused a wake by issuing a remote wakeup (3) May 10 12:08:33 Rays-Mac-Pro kernel[0]: HID tickle 137 ms May 10 12:08:33 Rays-Mac-Pro kernel[0]: EIR is not supported. From Diagnostic Messages 5/10/11 12:07:24.338 PM netbiosd: netbiosd lifecycle event tracer com.apple.message.domain: com.apple.netbiosd.lifecycle com.apple.message.signature: sleep com.apple.message.result: noop 5/10/11 12:08:33.139 PM loginwindow: loginwindow SleepWakeCallback will power on, Currenttime:5/10/2011 12:08:33.139 PM - Waketime:5/10/2011 12:08:33.000 PM = Deltatime:0.138658941 com.apple.message.domain: com.apple.loginwindow.logs com.apple.message.signature: will power on event received com.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0 com.apple.message.value: 0.138658941 com.apple.message.value2: 0 com.apple.message.result: noop 5/10/11 12:08:34.655 PM netbiosd: netbiosd lifecycle event tracer com.apple.message.domain: com.apple.netbiosd.lifecycle com.apple.message.signature: network change com.apple.message.result: noop 5/10/11 12:08:36.261 PM netbiosd: netbiosd lifecycle event tracer com.apple.message.domain: com.apple.netbiosd.lifecycle com.apple.message.signature: network change com.apple.message.result: noop 5/10/11 12:08:39.989 PM powerd: Sleep: Success - AC - Software Sleep com.apple.message.domain: com.apple.powermanagement.sleep com.apple.message.signature: Success com.apple.message.value: 0 com.apple.message.result: Success com.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0 com.apple.powermanagement: pmlog 5/10/11 12:08:39.989 PM powerd: Wake: Success - AC - EHC2 com.apple.message.domain: com.apple.powermanagement.wake com.apple.message.signature: Success com.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0 com.apple.message.result: Success com.apple.powermanagement: pmlog 5/10/11 12:08:39.989 PM powerd: Hibernate Statistics com.apple.message.domain: com.apple.powermanagement.hibernatestats com.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0 com.apple.message.signature: hibernatemode=0 com.apple.message.value: 0 com.apple.message.value2: 0 com.apple.powermanagement: pmlog 5/10/11 12:08:39.991 PM blued: Default trackpad found com.apple.message.signature: Default Trackpad com.apple.message.domain: com.apple.bluetooth.HID Link to comment Share on other sites More sharing options...
blackosx Posted May 10, 2011 Share Posted May 10, 2011 Hi rayap I don't think we'll find anything in those log files. For reference though, the contents of my logs look pretty similar to yours. I'm looking to the ACPI tables, maybe the FACS, FADT or DSDT. Though TBH, I have nothing solid to work from, just guess work for now. Link to comment Share on other sites More sharing options...
allenwkk Posted May 10, 2011 Share Posted May 10, 2011 I have a quick and dirty fix... just set Bios to skip on error instead of waiting for F1. Boot goes on and actually all Bios settings are as original before using the SLEEP. Link to comment Share on other sites More sharing options...
Vlada. Posted May 11, 2011 Share Posted May 11, 2011 I have a quick and dirty fix... just set Bios to skip on error instead of waiting for F1. Boot goes on and actually all Bios settings are as original before using the SLEEP. Heh, nice but I'd rather prefer that we find proper solution… I've EXACTLY the same symptoms here as I’ve mentioned before but I’ve noticed one strange thing... in snow leopard auto-sleep never worked (always needed auto-script sleep "rip3lan"), instead in lion it works vanilla.... Good catch… I was become aware of that today, when I was left my room on 15 minutes… As for SL auto-sleep issue, I’m using Please Sleep… Well, I don't know… First I was thinking that this is ICH9 chipset error only, but obviously it's not… It catches ICH10 too… Then I was suspect that perhaps Device (EHCI) could be related with this little issue, but again I was wrong… After I was made a couple of tests it appears eventually, that is not the problem (or at least not in my case)… I really don't have a clue now, because it's seems that there is no pattern or at least I can't see any. Maybe we should put on pile all elements from the DSDT code related with sleep and then start from there… Man, it would be nice if we could locate same motherboard in two different computers, where one haves CMOS error problem and other one don’t. Then we could just simply compare DSDT-s from both computers and easily locate what’s causing all this… Link to comment Share on other sites More sharing options...
nexus77777 Posted May 11, 2011 Share Posted May 11, 2011 Arg, still no joy with this trouble, same for me on each Lion rev. on EP45-DS3 Q6700 ... All working perfect on SL...auto sleep only with MacOs partitions, not working with dual boot Win7, even with boothfs mod... but manual sleep working... Hope a good genie will find the fix... regards... Link to comment Share on other sites More sharing options...
JUN Ho Posted May 11, 2011 Share Posted May 11, 2011 I have a same issue. My hack machine is Asus P5K-E Wifi. I found one temporary solution for this issue. Use AppleRTC.kext of snow leopard. It's not a fundamental solution, but it works for me. Link to comment Share on other sites More sharing options...
stellarola Posted May 11, 2011 Share Posted May 11, 2011 I have a same issue. My hack machine is Asus P5K-E Wifi. I found one temporary solution for this issue. Use AppleRTC.kext of snow leopard. It's not a fundamental solution, but it works for me. I can confirm this works. So now it seems to be some sort of RTC issue? Interesting. -Stell Link to comment Share on other sites More sharing options...
blackosx Posted May 11, 2011 Share Posted May 11, 2011 Use AppleRTC.kext of snow leopard. It's not a fundamental solution, but it works for me. Thanks for the nice work-around JUN Ho. This'll help for now until the problem with Lion's kext is found. Link to comment Share on other sites More sharing options...
stellarola Posted May 11, 2011 Share Posted May 11, 2011 Here's a link to the 10.6.7 & 10.7 variants. http://cl.ly/1I412a3J0v012I0q3J0t -Stell P.S. - Now if I could just get that Mac App Store GUID error, i'd be a happy camper. EDIT: App Store issue fixed! Link to comment Share on other sites More sharing options...
Vlada. Posted May 11, 2011 Share Posted May 11, 2011 Heh, well me on the other hand bothers, why from first DP2 version my DSDT patch for NVidia graphics doesn't work anymore, but only NVEnabler64.kext... hmm... As for this kext switching maneuver, well I can also confirm that this method works...! And again I don't like the way and especially HDD sound in a moment when my computer enters sleep... We’ll definitively need to find proper fix for this… Link to comment Share on other sites More sharing options...
rayap Posted May 11, 2011 Author Share Posted May 11, 2011 Hey this rollback works. Thanks JUN Ho. No apparent changes in the console msgs, wonder what these are in a real mac. Link to comment Share on other sites More sharing options...
stefano.85 Posted May 12, 2011 Share Posted May 12, 2011 Hey this rollback works. Thanks JUN Ho. No apparent changes in the console msgs, wonder what these are in a real mac. Hey works here too on my p5q... tnx for the trick!....anyway hope that this can be fixed soon...just to be more vanilla in the future EDIT: I don't know if it's related... but this trick solved me another problem that i always had since the first build of lion: Google chrome always prevented my system to shutdown or restart when remained open, the only solution so far was to kill it and then the restart/halt goes well.... maybe i can find in you a kind of confirmation. <--- the problem isn't resolved.... for what i've read there's a problem with chrome account synchronization: http://code.google.com/p/chromium/issues/detail?id=44321 Cheers Link to comment Share on other sites More sharing options...
edgar87 Posted May 12, 2011 Share Posted May 12, 2011 Thanks JUN Ho, it worked for me too! Link to comment Share on other sites More sharing options...
juanerson Posted May 12, 2011 Share Posted May 12, 2011 Maybe (just a idea) the sort of RTC issue coming from some fixed DSDT, I don't know perhaps reverting back the prior fix to default Length value (0xZZ) from 0x02, AND/OR leaving the factory IRQ in the Device. Please sorry my english. Good Luck. Link to comment Share on other sites More sharing options...
miliuco Posted May 12, 2011 Share Posted May 12, 2011 Same issue here with cmos reset after sleep. Dsdt works fine in SL. Not tried yet RTC kext solution. Link to comment Share on other sites More sharing options...
allenwkk Posted May 13, 2011 Share Posted May 13, 2011 Snow RTC roll back works for me... Now sleep without error in CMOS Bios. Link to comment Share on other sites More sharing options...
Recommended Posts