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

[blackosx]

I'm back from my trip away and while on my trip away I'd been monitoring this topic via my iPhone and seen some fantastic progress here. Thanks DHP for pitching in with some expert bin patching ideas. I had begun bin patching trials myself before I went away but it looks like I no longer need to?

 

@rayap, well done with your testing and continued exploration. To save re-inventing the wheel, can you post a link for downloading the patched v1.4 AppleRTC.kext that works for you? (Best not directly post it here as that's against the rules, but a mediafire link or some other means will do). I will test it when I get a chance and report back my findings. Thanks

[LatinMcG]

im interested in this topic. i have sleep reset with 0x02 lengths for RTC in snow. inspiron 1520.. nvidia.

 

let me get this straight.. to test i put 0x08 for both length ?

 

also since its against rules to post modded binary ? can a patcher be made ?

 

will read more of thread tonight. i have to go onsite .. ill be back later.

[rayap]

Try this with length 4 or 8.

 

http://www.mediafire.com/?e39p8jcawzotie8

 

Additionally, wake after auto-sleep gives spinning beach ball even for vanilla versions.

 

Edit: For Snow with length 4 or 8. No problem with auto-sleep

 

http://www.mediafire.com/?0w2k38hdth87qd4

 

EDIT: COPY PASTE URLS. FOR 64 bit ONLY

[blackosx]

Thanks for the post(s) but both are dead links?

Can you re-post / fix links?

 

2. Blocking both the call and jmp from setAlarmEnable to rtcRecordTracePoint in ver1.4 of AppleRTC resolves the cmos rests after sleep.

How did you block the call and jump?

I've just tried zeroing the two calls but booting 10.7 with it and selecting sleep causes a reboot. Where is the jump instruction?

 

What I tried:

rtcRecordTracePoint is located at 000032ec

The lines I zero'd out were:

+114	00003748  e89ffbffff			  calll		  0x1000032ec
+409	0000386f  e878faffff			  calll		  0x1000032ec

[JBraddock]

Thanks for the post(s) but both are dead links?

Can you re-post / fix links?

The links were pointed to wrong urls. Try these ones.

 

http://www.mediafire.com/?e39p8jcawzotie8

http://www.mediafire.com/?0w2k38hdth87qd4

[blackosx]

Thanks JBraddock. I'll try now.

 

EDIT:

The posted patched AppleRTC v1.4 doesn't work for me. I still get the CMOS reset after using sleep/wake on both 11A444d and 11459e. I've tried it also with changing my Device (RTC) length back to 0x04 too.

 

What patches were applied to that version? I've looked for the call and jump to rtcRecordTracePoint from setAlarmEnable and don't see any difference?

 

EDIT2:

Correction. The patched AppleRTC v1.4 does eliminate the CMOS reset after using sleep when booting with the kernel in 64-bit mode. Thanks.

[JUN Ho]

EDIT2:Correction. The patched AppleRTC v1.4 does eliminate the CMOS reset after using sleep when booting with the kernel in 64-bit mode. Thanks.

 

I confirm the patched AppleRTC v1.4 works in 64-bit mode. I test it Device (RTC) length 0x02,and 0x04.Both case works in 64-bit mode. No more CMOS reset after sleep/wake.But it doesn't work in 32-bit mode.I have the CMOS reset after sleep/wake when using Device (RTC) length 0x02.When I use Device (RTC) length 0x04, I cannot wake from sleep. Thanks Guys !!

[rayap]

I confirm the patched AppleRTC v1.4 works in 64-bit mode. I test it Device (RTC) length 0x02,and 0x04.Both case works in 64-bit mode. No more CMOS reset after sleep/wake.But it doesn't work in 32-bit mode.I have the CMOS reset after sleep/wake when using Device (RTC) length 0x02.When I use Device (RTC) length 0x04, I cannot wake from sleep. Thanks Guys !!

 

Will any expert soul patch it for 32-bit kernel mode. Would like to hear about wake after auto-sleep success in 64-bit mode. Thanks

 

EDIT: Wake after auto-sleep is ok on new install, possibly a local corruption issue. May attempt to do the changes for the 32-bit kernel mode too.TQ

 

EDIT2: This variant of AppleRTC.kext v1.4 is for 32-bit and 64-bit kernel

http://www.mediafire.com/?0w2k38hdth87qd4 See Post #114

[blackosx]

EDIT2: This variant of AppleRTC.kext v1.4 is for 32-bit and 64-bit kernel

http://www.mediafire.com/?0w2k38hdth87qd4

Thanks rayap. But isn't this v1.3.1 of the kext?

 

Also, what patches are you applying as I've been testing this morning with the suggestions posted by DHP and have had no luck. You reported success in post #98 using the change of 55 to C3 for function rtcWriteBytesAndCRC but that hasn't worked for me.

[rayap]

Hi blackosx,

 

DHP was asking to replace the start push(55) with return (C3) instruction in the procedure. I only made changes to the other procedure calls or jumps that refer to the earlier procedure. Replacing Calls with 9090909090 and jumps with C390909090. That's it!

 

EDIT: The MachO file size in 1.3.1 is 115k and in 1.4 131k.

Arrrrgh: The dreaded spinning beach ball is back after a few clean sleeps!!!

[blackosx]

DHP was asking to replace the start push(55) with return (C3) instruction in the procedure.

That's what I was using to test with.

 

I only made changes to the other procedure calls or jumps that refer to the earlier procedure. Replacing Calls with 9090909090 and jumps with C390909090. That's it!

Okay thanks for the explanation. So am I correct in guessing that earlier procedure is updateChecksum or setAlarmEnable based on what you said in post #102 ?

No probs. I've found the differences in the v1.4 AppleRTC binary from the link posted by JBraddock.

The jump in recordTracePointHandler, and the call and jump in SetAlarmEnable.

 

EDIT: The MachO file size in 1.3.1 is 115k and in 1.4 131k.

Yes. That's one of the reasons why I asked if the patched AppleRTC you posted in post #110 was v1.3.1 and not v1.4 because the AppleRTC binary in that is 115K.

[rayap]

Yes. That's one of the reasons why I asked if the patched AppleRTC you posted in post #110 was v1.3.1 and not v1.4 because the AppleRTC binary in that is 115K.

 

Hey you are correct man. Hope this time is right.

 

http://www.mediafire.com/?326xarf4mxuo6xb

[blackosx]

That's the one. I only had time for one test but it worked great with the kernel in 32-bit mode. Thanks

Off to watch the Champions League final now. I'll look further at the patched kext hopefully later.

 

EDIT:

That patched kext you've posted is working just fine here. Well done with your work rayap

I've put your changes in to a command which can be run in Terminal against AppleRTC v1.4:

sudo perl -pi -e 's|\xE9\x91\x06\x00\x00|\xC3\x90\x90\x90\x90|; s|\xE8\x7D\xFB\xFF\xFF|\x90\x90\x90\x90\x90|; s|\xE9\xFF\xF9\xFF\xFF|\xC3\x90\x90\x90\x90|; s|\xE8\x1F\x07\x00\x00|\x90\x90\x90\x90\x90|; s|\xE8\xF4\xFA\xFF\xFF|\x90\x90\x90\x90\x90|; s|\xE8\xA0\xF9\xFF\xFF|\x90\x90\x90\x90\x90|' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

If anybody tests this and it doesn't work then please report back.

[JUN Ho]

That's the one. I only had time for one test but it worked great with the kernel in 32-bit mode. Thanks

Off to watch the Champions League final now. I'll look further at the patched kext hopefully later.

 

EDIT:

That patched kext you've posted is working just fine here. Well done with your work rayap

I've put your changes in to a command which can be run in Terminal against AppleRTC v1.4:

sudo perl -pi -e 's|\xE9\x91\x06\x00\x00|\xC3\x90\x90\x90\x90|; s|\xE8\x7D\xFB\xFF\xFF|\x90\x90\x90\x90\x90|; s|\xE9\xFF\xF9\xFF\xFF|\xC3\x90\x90\x90\x90|; s|\xE8\x1F\x07\x00\x00|\x90\x90\x90\x90\x90|; s|\xE8\xF4\xFA\xFF\xFF|\x90\x90\x90\x90\x90|; s|\xE8\xA0\xF9\xFF\xFF|\x90\x90\x90\x90\x90|' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

If anybody tests this and it doesn't work then please report back.

 

Hi, blackosx ! I test your trminal script, but it doesn't work.

[Time2Retire]

We Really need to understand what is happening and fix it through other proper means.

What do you think people here are trying to do? Nobody wants a bin-patch when there is no need for it, but until someone comes up with a better idea... We first need to figure out where and what in the binary is causing the reset, to narrow it down – otherwise it is like looking for a needle in a haystack – and then we have to figure out if and how it can be fixed.

 

Might be as simple as adding a missing property or a FACP change, but we still don't know. And when it is related to some kind of alarm, then you have to find the right spot to fix it.

 

Good luck with that, because as you know, my time here is running up pretty quick now.

[blackosx]

@JUN Ho

Thanks for testing it. I only ran it once here last night against the original AppleRTC v1..4 in 11459e to test and it worked fine. Did you use it against the version from 11459e? as STLVNUB has correctly posted, there are differences between the versions of the AppleRTC v1.4 binary supplied with different 10.7 developer preview releases.

 

md5 for 11A444d = 7ebf4be8181cace39c6cc25d3ec5a4f3

md5 for 11459e = ae97b51092c3ec915f1cc9bb9d014e61

 

This kind of patching will only break other functions and could potentially be dangerous.

Yes. This is not by any means a final fix. It's just something that's come from me working through and understanding rayap's changes.

 

EDIT:

Here's a revised command line which checks the md5 of the original AppleRTC v1.4 from 11A59e before patching. Just copy and paste this in to terminal.

checkvers=$( md5 /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC | awk '{print $4}' ); if [ ${checkvers} =  "ae97b51092c3ec915f1cc9bb9d014e61" ]; then echo "Patching Now…"; sudo perl -pi -e 's|\xE9\x91\x06\x00\x00|\xC3\x90\x90\x90\x90|; s|\xE8\x7D\xFB\xFF\xFF|\x90\x90\x90\x90\x90|; s|\xE9\xFF\xF9\xFF\xFF|\xC3\x90\x90\x90\x90|; s|\xE8\x1F\x07\x00\x00|\x90\x90\x90\x90\x90|; s|\xE8\xF4\xFA\xFF\xFF|\x90\x90\x90\x90\x90|; s|\xE8\xA0\xF9\xFF\xFF|\x90\x90\x90\x90\x90|' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC; else echo "Wrong md5, not patched"; fi

 

We Really need to understand what is happening and fix it through other proper means.

Absolutely. I've read lots, tried many things and I'll keep looking for a viable solution without patching the Apple binary.

 

Might be as simple as adding a missing property or a FACP change, but we still don't know. And when it is related to some kind of alarm, then you have to find the right spot to fix it.

I did spot the RTC values in the FACP (FADT) previously when I was reading up about the RTC clock and it's internal registers. Maybe it's time for me to re-visit it.

[Time2Retire]

This is interesting. I was testing something else, but AppleSMBIOS.kext didn't load and then BOOM. I got this message about having only one ram bank. That's not true. I never get to see this on my Sandy Bridge hack. Seems like there's something in SMBIOS structures for RTC too. Please check this!

[stellarola]

Good finds everyone!

 

-Stell

[blackosx]

This is interesting. I was testing something else, but AppleSMBIOS.kext didn't load and then BOOM. I got this message about having only one ram bank. That's not true. I never get to see this on my Sandy Bridge hack. Seems like there's something in SMBIOS structures for RTC too. Please check this!

Thanks for the post. I've had a look at my end to see if I can see anything, but nothing has turned up yet.

 

I've tried booting with and without AppleSMBIOS.kext with my Device RTC length set to both 4 and 2, but I only see RTC: Only single RAM bank (128 bytes) in the kernel.log if RTC length is set to 2.

 

I've also looked at my SMBIOS using your smbios2struct3 tool from RevoBoot, and also from Chameleon's boot log as Kabyl previously added the original SMBIOS info to it, but I don't see anything useful there.

 

Looking at Apple's source code for SMBIOS.h I see in the Firmware Volume Description (Apple Specific - Type 128)

FW_REGION_NVRAM	  = 3,

Could that be anything?

 

I'll otx the 11459e AppleSMBIOS binary to see if I see anything there, but otherwise if you could throw anything else in to the mix here (of course knowing your time is valuable) then please do.

[rayap]

All seems well with DP4's (Build 11A480b) AppleRTC kext after applying blackosx perl patch. It appears there is no change in code from previous build either.

[blackosx]

Thanks for the confirmation rayap as I haven't tried applying the previous patch from here yet.

I see something has changed with the AppleRTC binary in 11480b as the md5 = bd73f8f6c1d5ff73392e830f280fbd31 compared with the values posted here.

 

EDIT:

Just grabbed some time to play with DP4 (11A480b) and I no longer have the CMOS reset using the vanilla AppleRTC.kext.

The md5 of the binary in AppleRTC.kext = bd73f8f6c1d5ff73392e830f280fbd31

 

So patching is no longer required. Can somebody else please confirm this to make sure I'm not seeing things?

Ignore that.. I forgot that I had to do a sleep/wake cycle before the CMOS reset occurs.. Doh!

 

EDIT2

Yep. Just confirming as rayap posted that this hack for the CMOS reset works for DP4.

[-aKy-]

Can confirm that this fix works, but I noticed that Auto-Sleep won't work correct. Monitor will turn off, but the PC won't shut down, the fans keep spinning. But in order to get back to the desktop, I have to "wake" up the system like I do when i put it into sleep manually.

 

Update: for testing Auto-sleep i put it to sleep after one minute in system prefs, reverted it after testing, but the system still trys to sleep after one minute. Maybe anyone could check if this happens on other machines too?

 

 

Will try unpatched AppleRTC and report back.

 

Update 2: Reverted back to original RTC, put it to never sleep and patched again to have manual sleep functionality, PC won't sleep after one minute now.

[kitmac]

Ok my system will shut my monitors off but my computer fans keep running....

Have to do a hard reset with the power button on the tower.

But my CMOS seems to be unaffected

Patched RTC doesnt seem to make a difference for me.

 

Stell i know u used to have my Mboard. Any advice?????

 

also my ethernet doesnt show. Using USB wireless for now.

 

I hear applehpet causes these types of issues. that true?

[rayap]

@-aKy-

Of course you are aware that even if you set idle-sleep to 1minute in sysprefs, the rig only hibernates after several (maybe many) minutes unlike the display.

[-aKy-]

Checked again and waited for more than 10 minutes, but system didn't hibernate. How long do you think it could take?