Jump to content
rayap

CMOS Resets on Restarts after Sleep and Wake in 10.7 (Lion)

486 posts in this topic

Recommended Posts

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… :(

Share this post


Link to post
Share on other sites
Advertisement
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.

post-331032-1304808479_thumb.png

 

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

Share this post


Link to post
Share on other sites

Another thing that happens is the ethernet is disabled after wake. Had to replug, ifconfig down/up does not work.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 :lol:

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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… :D

 

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…

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

 

:unsure::unsure:

Share this post


Link to post
Share on other sites
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.

 

;):P

 

I can confirm this works. So now it seems to be some sort of RTC issue? Interesting.

 

 

-Stell

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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…

Share this post


Link to post
Share on other sites

Hey this rollback works. Thanks JUN Ho.

No apparent changes in the console msgs, wonder what these are in a real mac.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Same issue here with cmos reset after sleep. Dsdt works fine in SL. Not tried yet RTC kext solution.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×