485 replies to this topic

[blackosx]

I have this problem also.
10.7 (all preview releases) will sleep and wake just fine. But after doing so, CMOS will be reset for next boot after restart or shutdown.

I've also tried using hibernation with sudo pmset -a hibernate mode 1, but it doesn't make any difference.

[rayap]

This kernel message appears after sleep and wake:-

kernel: IOPMrootDomain: client 0xffffff7f80bb1e7c returned 120000000 for kIOMessageSystemWillSleep

It appears the client vetoes proper sleep so preventing some housekeeping tasks and prompting the above msg instead of a successful 'System Sleep' msg.

Anyone knows what the client address refers to?

Edit: Found pointing to IOGraphicsFamily.kext

[kjellamund]

Same {censored}in problem here!

CMOS reset after try to wake up from sleep!

Gigabyte x58a UD7.

[stellarola]

Related?

http://www.projectos...?showtopic=1549

Stell

[MaLd0n]

annoying little problem
 B.png   757bytes   130 downloads

[Vlada.]

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…

[blackosx]

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.
 CMOS_values.png   83.7KB   123 downloads

What does this show? well I'm not really sure, but it might be food for thought for someone to build upon.

UPDATE:
[s]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

[rayap]

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

[Detrich]

I'm pretty sure, the problem is chameleon.

[blackosx]

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.

[allenwkk]

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.

[blackosx]

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.

[Goron]

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

[stefano.85]

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

[rayap]

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 kIOMessageSystemWillSleepMay 10 12:07:27 Rays-Mac-Pro kernel[0]: May 10 12:08:33 Rays-Mac-Pro kernel[0]: Wake reason: EHC2May 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 msMay 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 tracercom.apple.message.domain: com.apple.netbiosd.lifecyclecom.apple.message.signature: sleepcom.apple.message.result: noop5/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.138658941com.apple.message.domain: com.apple.loginwindow.logscom.apple.message.signature: will power on event receivedcom.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0com.apple.message.value: 0.138658941com.apple.message.value2: 0com.apple.message.result: noop5/10/11 12:08:34.655 PM netbiosd: netbiosd lifecycle event tracercom.apple.message.domain: com.apple.netbiosd.lifecyclecom.apple.message.signature: network changecom.apple.message.result: noop5/10/11 12:08:36.261 PM netbiosd: netbiosd lifecycle event tracercom.apple.message.domain: com.apple.netbiosd.lifecyclecom.apple.message.signature: network changecom.apple.message.result: noop5/10/11 12:08:39.989 PM powerd: Sleep: Success - AC - Software Sleepcom.apple.message.domain: com.apple.powermanagement.sleepcom.apple.message.signature: Successcom.apple.message.value: 0com.apple.message.result: Successcom.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0com.apple.powermanagement: pmlog5/10/11 12:08:39.989 PM powerd: Wake: Success - AC - EHC2com.apple.message.domain: com.apple.powermanagement.wakecom.apple.message.signature: Successcom.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0com.apple.message.result: Successcom.apple.powermanagement: pmlog5/10/11 12:08:39.989 PM powerd: Hibernate Statisticscom.apple.message.domain: com.apple.powermanagement.hibernatestatscom.apple.message.uuid: 72DD5B0F-C354-4AD4-B6AF-DEDEBEFD52D0com.apple.message.signature: hibernatemode=0com.apple.message.value: 0com.apple.message.value2: 0com.apple.powermanagement: pmlog5/10/11 12:08:39.991 PM blued: Default trackpad foundcom.apple.message.signature: Default Trackpadcom.apple.message.domain: com.apple.bluetooth.HID

[blackosx]

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.

[allenwkk]

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.

[Vlada.]

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…

[nexus77777]

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

[JUN Ho]

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.