Jump to content

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


  • Please log in to reply
485 replies to this topic

#401
zoltankr

zoltankr

    zoliky

  • Members
  • PipPipPipPipPipPip
  • 427 posts
  • Gender:Male
The On-board audio is disabled (EP45-UD3P). Same CMOS Reset.

#402
cartri

cartri

    Just a Cone

  • Donators
  • 407 posts
  • Location:Brazil

Hey, Cartri

You may be on to something here. Just did a clean install of 10.7 with tonymacx86 database dsdt for GA-X58A-UD7 Rev.1.0 F7 dsdt.

Am having problem that it will go to sleep and wake, but no graphics on wake so have to hard power off and reboot. Getting this CMOS reset problem so went looking and found this thread. Was going to try the fixes you suggest one by one and see if any of them worked. Made the one change to DSDT from database - same as above to add _FIX. Compiled no erros. Replaced DSDT.aml in /Extra with compiled file and hit apple -> sleep. Rig went to sleep, no problem. Waited a few minutes and hit the left mouse button. Disc spun up, DVD-RW lights came on but still no graphics (I know, but that's for another topic). Still, hard power off at the surge supressor. Power back on, hit the start button and normal boot - no CMOS reset! I have attached 3 DSDT files - one extracted with DSDTSE for winXP with the iasleme file replaced with latest so it will work in Win7, one from tonymac86 dsdt database I used on original install and the last with the _FIX. That was all I did to it.



Adding _FIX to RTC device on GA-P35-DS4 has no effect on CMOS reset.


I have more to read in this topic, sorry for the absence after so many shots, just updated my os to lion final, finally. I am no fan of sleep, everything i did about this in the old times was due to requests, as i leave my machine always on (I hate the fact that Apple Cinema Display has no power button, no button at all btw, but i just unplug the cord when I go to sleep).
Still having big problems with graphics drivers, using a salad of 10.6.7 controllers together with 10.7.0 opengl (X3000) drivers, so i guess right now my system is not a comparison yet.

The _FIX seems to be an incomplete fix to the problem, as always I was just shooting everywhere, and I still think that if something has to be done to the CMOS in the ACPI we should start by the way chameleon is reconstructing ACPI himself. This is only opinion, But The other posting i did about the RTC registers that may be set to read-only may avoid osx from changing the RTC. (As I said, this can solve the problem, or create others, if the known bits were made also RO)

About Going Bald's machine, its valid to remember that, differently from most gigabyte first x58 bioses it uses a 2MB (16Mbit) chip, which lengths 0x8, maybe this is a relevant difference as the new checksum may be considering the whole cmos size, maybe not. Also valid to remember that the new bioses for these 2MB chips are hybrid EFI-Bios in order to give native support to GUID, and the module is giant.

Sorry for being too busy with my own system in my free time, I still fight my graphics drivers, the normal patch in vanilla 5000controller doesn't work for me for some reason. When I fix this I'll be back here, and able to make my own tests. With tseug, black, mm67 and everyone else here trying a fix on this, soon or later we will catch the mouse. I will surely come back to this thread, it interests me, besides of not using sleep, and take a better look over everybody's gigabyte dsdts to better opine.
For now, i keep receiving the posts by mail.

BTW, Going Bald, how are your peripherals? New appleHDA is constructing my audio from the main module, i have no more need to rewrite the main module config data into a DSM... may this really have something to do with peripherals not waking? Much to check, I am just raising some questions for thinking, I know it is nothing new, but it was what popped to my mind at the time.

See ya!

----
quick edit: Are you guys CID"ing" your power button? Cause with a normal hid it will be a sleep button, as long as you have a F4 size FACP (instead of chameleon's facp patch)

EDIT2:
Fixing or not an IRQ8 to the RTC will not make real difference except its booted with this IRQ set, as it is not used as an IRQ would normally use, but a switch to ich10 activate or not RTC as a slave IRL from LPC. IRQ8 can only be generated internally, like 0 & 2. This info is only valid for ich10 based systems

#403
MartyBoston

MartyBoston

    InsanelyMac Protégé

  • Members
  • Pip
  • 1 posts

Amended 24th day of June, 2011

On Lion DP1-4 installations, after using sleep and wake in the system normally, BIOS reports CMOS Checksum Error on reboot or boot after shutdown. It seems that the new AppleRTC.kext v1.4 added functionatality is causing this Error.

Initially, a workaround suggested by JUN Ho is to use the AppleRTC.kext from SnowLeopard

Then by blocking a few jumps and calls in the procedures of AppleRTC.kext, the Checksum Error was overcome. It appears APPLE has left in-situ much of their realtime testing code in this kext and these modifications do not apparently affect their basic functionatility in normal cases.
On further investigation by tseug and with the assistance of his DumpCMOS.kext , an updated patch (post# 217) was prepared by blackosx. This patch for vanilla AppleRTC.kext is effective on the latest build 11A494a. (besides also on recent builds)

This solution will not affect those osx86 setups which inherently have Sleep or Wake problems. However, it will overcome the CMOS Checksum Error caused by RTC register length of 0x04 or 0x08 in DSDT and eliminate log msg RTC: Only single RAM bank (128 bytes) if, when a RTC register length of 0x02 is used.

Added 2nd day of July, 2011
New patch for AppleRTC.kext of Lion GM - Build 11A511 by tseug (Post #248). The binary patch now, is a single unconditional jump for each arch to bypass Checksum changes.

Added 10th day of July, 2011
An alternate patch for AppleRTC.kext of Lion GM. (Post # 340)


I have a Gigabyte GA-EX58-UD5 (rev. 1.0) F13u bios. I installed Lion using a DSDT file from tonymacx86 for the F12 bios and #####. Both the F12 and F13u BIOS have the CMOS reset problem.

What is the benefit of patching the 10.7 AppleRTC.kext as opposed to just using the SL 10.6.8 kext if the SL kext solves the problem? What about the ElliottForceLegacyRTC.kext?

If one does decide to patch the 10.7 kext, which of the several patches listed on this site should one use?

Thanks,
MartyBoston

#404
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 165 posts
  • Gender:Male

What is the benefit of patching the 10.7 AppleRTC.kext as opposed to just using the SL 10.6.8 kext if the SL kext solves the problem? What about the ElliottForceLegacyRTC.kext?

If one does decide to patch the 10.7 kext, which of the several patches listed on this site should one use?


There is no definitive answer. All are sharing their experiences with their machines to contribute towards this community. You need to try any method you fancy and to tell us which works best for you. Reading the posts may help you decide which to use for your particular setup.

#405
xavierpj

xavierpj

    InsanelyMac Protégé

  • Members
  • Pip
  • 1 posts
Having the same problem with my P55-US3L, i5-650, geforce 8800gts... sleep fine in SL but CMOS reset in Lion....

There may be more to this than just patching and more issues Apple's end judging by:-

Apple forums...

a lot of actual Apple hardware owners are having issues with sleep....

#406
Johnny_G

Johnny_G

    InsanelyMac Protégé

  • Members
  • Pip
  • 2 posts
Still looking for a fix to this, I'm on a g41-es2l, adding the SL sleepenabler didn't made any difference, deleting the nullcpupowermanagement allows it to sleep and waking up properly most of the time, sometimes graphics on wake won't load back again requiring a hard reset with the subsequent CMOS issue everyone described here; next I will replace the original AppleRTC.kext with the patched one, and/or try the read-only option.

#407
LatinMcG

LatinMcG

    Insanely digesting DSDT

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 2,509 posts
  • Gender:Male
  • Location:Tampa, Florida
guys with no wake. the realtek s site Lan driver gives me that problem. use Lnx2mac driver.

#408
chappcc

chappcc

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts

Thanks -- perfect fix for EP45-UD3P

I applied the patch and on restart got the CMOS CHECKSUM ERROR screen. I allowed it to use the last known good boot and the system restarted normally. Should I see the CMOS CHECKSUM ERROR screen after applying this patch?

MY MB is a EP45-UD3P

#409
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 165 posts
  • Gender:Male

I applied the patch and on restart got the CMOS CHECKSUM ERROR screen. I allowed it to use the last known good boot and the system restarted normally. Should I see the CMOS CHECKSUM ERROR screen after applying this patch?

MY MB is a EP45-UD3P


You got what you last started(1) with - when you start(2) with the patched kext you should not see it @ the next start(3).

#410
chappcc

chappcc

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts

You got what you last started(1) with - when you start(2) with the patched kext you should not see it @ the next start(3).

Works fine - just as you describe

#411
cubswinfllclssic

cubswinfllclssic

    InsanelyMac Protégé

  • Members
  • PipPip
  • 85 posts
  • Gender:Male
  • Location:Elmhurst, IL
Thanks to all who worked on this!

Running the latest patch on AppleRTC fixed my sleep problem. GA-P35-DS3L Rev 2.0 with a DSDT created from DSDT Auto-Patcher.

Thank you!

#412
jsl

jsl

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 331 posts

Amended 24th day of June, 2011

On Lion DP1-4 installations, after using sleep and wake in the system normally, BIOS reports CMOS Checksum Error on reboot or boot after shutdown. It seems that the new AppleRTC.kext v1.4 added functionatality is causing this Error.

Initially, a workaround suggested by JUN Ho is to use the AppleRTC.kext from SnowLeopard

Then by blocking a few jumps and calls in the procedures of AppleRTC.kext, the Checksum Error was overcome. It appears APPLE has left in-situ much of their realtime testing code in this kext and these modifications do not apparently affect their basic functionatility in normal cases.
On further investigation by tseug and with the assistance of his DumpCMOS.kext , an updated patch (post# 217) was prepared by blackosx. This patch for vanilla AppleRTC.kext is effective on the latest build 11A494a. (besides also on recent builds)

This solution will not affect those osx86 setups which inherently have Sleep or Wake problems. However, it will overcome the CMOS Checksum Error caused by RTC register length of 0x04 or 0x08 in DSDT and eliminate log msg RTC: Only single RAM bank (128 bytes) if, when a RTC register length of 0x02 is used.

Added 2nd day of July, 2011
New patch for AppleRTC.kext of Lion GM - Build 11A511 by tseug (Post #248). The binary patch now, is a single unconditional jump for each arch to bypass Checksum changes.

Added 10th day of July, 2011
An alternate patch for AppleRTC.kext of Lion GM. (Post # 340)

The only way for my Asus P6TSE and P5QPRO MBs in Lion GM to correct this CMOS reset error after Sleep/Wake is
1. Install ElliottForceLegacyRTC.kext in /S/L/E
2. Disable Legacy USB support in BIOS and use PS2 keyboard instead

So maybe someone can figure out how to modify USB settings in DSDT to solve it.

#413
HFW

HFW

    InsanelyMac Protégé

  • Members
  • PipPip
  • 84 posts
  • Gender:Male
  • Location:England
Anyone still working on this? =/
Been trying a few of my own undocumented DSDT experiments... Every single one I still get CMOS reset. I did manage to fix the reboot/black screen I used to get with unpatched AppleRTC.kext 1.4 on wake, not too sure what fixed it but the last thing I remember changing was alignment in Device (RTC) to 1, as posted by cartri.

And I ran into a strange message on wake in kernel.log:

Aug 11 13:48:11 Mac-Pro kernel[0]: Wake reason: RTC UHC6 (Alarm)
Aug 11 13:48:11 Mac-Pro kernel[0]: RTC: maintenance alarm 2011/8/11 14:48:02, sleep 2011/8/11 12:48:05
Aug 11 13:48:11 Mac-Pro kernel[0]: The USB device BCM2046B1 (Port 2 of Hub at 0x5a000000) may have caused a wake by issuing a remote wakeup (2)

RTC maintenance alarm? :S Not seen that before myself :withstupid:

Specs in sig...

#414
helob

helob

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 218 posts

Thanks to all who worked on this!

Running the latest patch on AppleRTC fixed my sleep problem. GA-P35-DS3L Rev 2.0 with a DSDT created from DSDT Auto-Patcher.

Thank you!

TQ for sharing with us your solution to sleep'
Which latest patch on AppleRTC are you referring to?
Would appreciate if you can list the patch code or where it come from?
Thank You

#415
stellarola

stellarola

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 682 posts
  • Gender:Male
  • Location:Lextown, KY

TQ for sharing with us your solution to sleep'
Which latest patch on AppleRTC are you referring to?
Would appreciate if you can list the patch code or where it come from?
Thank You


Check out the main thread.

#416
Rage-

Rage-

    InsanelyMac Protégé

  • Members
  • Pip
  • 3 posts

Posted by: stellarola May 11 2011, 11:02 PM
Here's a link to the 10.6.7 & 10.7 variants. http://cl.ly/1I412a3J0v012I0q3J0t

It would be nice to put this into topic's first message too, along with Lion's AppleRTC patches. For me only 10.6.7 AppleRTC rollback worked. Sticking to the first message should be great time saver for those who searches for rollback.

#417
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,170 posts
  • Gender:Male
  • Location:UK
Just a quick note about the 10.7.1 update. It does not touch the AppleRTC binary so if you've already patched it for 10.7 then there's no need to re-do it.

For reference, I'm using the patch rayap posted here.

#418
beelzebozo

beelzebozo

    InsanelyMac Protégé

  • Members
  • Pip
  • 8 posts
I can confirm that AppleRTC.kext 1.3.1 from 10.6.8 works with 10.7/10.7.1 and takes care of the CMOS issue on my z68X-UDH3-B3 with a DSDT installed.

#419
ugokind

ugokind

    InsanelyMac Deity

  • Donators
  • 1,714 posts
  • Gender:Male
  • Location:10100
  • Interests:Apicoltura
    Mac
    Linux
    Homebrew
    Australia
    Spremermilcervello

@rimmi2002


not working on acer 5930 and zotac geforce 9300

#420
oSxFr33k

oSxFr33k

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 850 posts
  • Gender:Male
  • Interests:Sound and Graphic Design. Electronics in general.

I can confirm that AppleRTC.kext 1.3.1 from 10.6.8 works with 10.7/10.7.1 and takes care of the CMOS issue on my z68X-UDH3-B3 with a DSDT installed.



A patched AppleRTC.kext or vanilla? I have to try this on my GA-Z68X-UD4-B3



Edited Next Day:

NO CMOS reset with next 10.6.8. However I do get an additional message that I do not get with 10.7.1 kext.


Graphics suppressed 7984 ms


10.6.8 and 10.7.1 have same message upon wake USB3/Firewire/Airport disconnect. I am not sure if the USB3 disconnects or just resets? For sure the Firewire and Airport do.


PXHCD    ResetControllerState - reseting saved status for 4 root hub portsPXHCD    ResetControllerState - reseting saved status for 4 root hub portsAirPort: Link Down on en0. Reason 8 (Disassociated because station leaving).         0 [Time 1314809940] [Message Wake reason: ethernet EHC1 (Network)no card!no card!AppleFWOHCI_AsyncReceive::waitForDMA - context not going inactive.AppleFWOHCI_AsyncReceive::waitForDMA - context not going inactive.FireWire GUID ffffffffffffffff is invalid!       0        0 AppleUSBCDC: start - initDevice failed       0        0 AppleUSBCDC: start - initDevice failedGraphics suppressed 7984 msFireWire GUID ffffffffffffffff is invalid!HID tickle 12915 msFireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!FireWire GUID ffffffffffffffff is invalid!






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy