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

#101
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK
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

#102
LatinMcG

LatinMcG

    Insanely digesting DSDT

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 2,509 posts
  • Gender:Male
  • Location:Tampa, Florida
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.

#103
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male
Try this with length 4 or 8.

http://www.mediafire...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...0w2k38hdth87qd4

EDIT: COPY PASTE URLS. FOR 64 bit ONLY

#104
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK
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


#105
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

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...e39p8jcawzotie8
http://www.mediafire...0w2k38hdth87qd4

#106
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK
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.

#107
JUN Ho

JUN Ho

    InsanelyMac Protégé

  • Members
  • Pip
  • 42 posts

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

#108
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male

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...0w2k38hdth87qd4 See Post #114

#109
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK

EDIT2: This variant of AppleRTC.kext v1.4 is for 32-bit and 64-bit kernel
http://www.mediafire...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.

#110
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male
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!!!

#111
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK

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.

#112
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male

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

#113
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK
That's the one. I only had time for one test but it worked great with the kernel in 32-bit mode. Thanks :P
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 :D
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.

#114
JUN Ho

JUN Ho

    InsanelyMac Protégé

  • Members
  • Pip
  • 42 posts

That's the one. I only had time for one test but it worked great with the kernel in 32-bit mode. Thanks :P
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 :D
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.

#115
STLVNUB

STLVNUB

    InsanelyMac Legend

  • Coders
  • 1,143 posts
  • Gender:Male
From what i can see, all versions of AppleRTC.kext for Lion are 1.4, but have different sizes for different builds, so the code offsets are different and thus the script will fail.

The build version that rayap posted does not tally with the build version of Lion that he has in his sig

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

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

#116
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu

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.

#117
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK
@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.

#118
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
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!

#119
stellarola

stellarola

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 682 posts
  • Gender:Male
  • Location:Lextown, KY
Good finds everyone! :(

-Stell

#120
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,161 posts
  • Gender:Male
  • Location:UK

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





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