57 replies to this topic

[rayap]

With the new AppleRTC kext version 1.5, got rid of CMOS Resets on my setup with this perl script [Edit: for arch=x86_64].Basically jumps over the checksum updates.

sudo perl -pi -e 's|\x75\x30\x89\xd8|\xeb\x30\x89\xd8|' /Extra/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

AppleRTC.kext v1.5 does not jive with Lion when in E/E (multi boot); leave it in S/L/E .

[blackosx]

Hi rayap - We meet again

Well done with your quick work here, though to be honest I haven't tried it yet as I don't even have ML installed. But at least I know where to come if and when I need it.

Regards
blackosx

EDIT:
This does the job nicely. Thanks rayap.

[stefano.85]

Hi rayap! you're fix works perfectly here on asus p5q MB, i've patched a copy of the original ML appleRTC.kext and just placed it into /E/E of the usb pendrive that i use to boot the OS leaving the original in S/L/E.
Tnx and cheers

[Riley Freeman]

I applied this old Lion fix to mine and it seems to have worked too. Yours is a bit more compact though.

[stellarola]

I'll need to check this out, but I believe rayap's edit allows for auto sleep and the original from Riley Freeman's post does not.

-Stell

EDIT: Auto-sleep works before patching AppleRTC in 10.8 DP1. However CMOS reset still occurs without patching. I'd like to see a KEXT that can override this edit altogether, but I'll save that for smarter men.

[stefano.85]

stellarola, on 20 February 2012 - 09:15 PM, said:

I'll need to check this out, but I believe rayap's edit allows for auto sleep and the original from Riley Freeman's post does not.

-Stell

LOL Stell we meet every time there's a new topic about sleep and applertc

[MARKSMART]

thanks for this fine way it works

[tseug]

Riley Freeman, on 19 February 2012 - 03:08 AM, said:

I applied this old Lion fix to mine and it seems to have worked too. Yours is a bit more compact though.

Thanks for testing it (so I won't have to)

It actually isn't less compact. The reason it is longer is to avoid matching on some relative address jumps that tend to change if the source code is changed so it's not completely accidental that it works In addition it patches both the 32-bit and 64-bit kernel.

[Riley Freeman]

Ah, thanks for the info tseug. I usually run in 64-bit mode so didn't notice that the other patch only works on the 64-bit kernel. I'll have to test yours for sleep as I don't use it. I only wanted the CMOS reset fix.

[tseug]

Riley Freeman, on 27 February 2012 - 12:05 AM, said:

Ah, thanks for the info tseug. I usually run in 64-bit mode so didn't notice that the other patch only works on the 64-bit kernel. I'll have to test yours for sleep as I don't use it. I only wanted the CMOS reset fix.

None of the patches are designed to do anything to sleep. They only fix the CMOS reset.

[M0rpheus]

Funny that it's not supposed to fix sleep but it does, for me also. I think it must fix somehow how the RTC works when it sleeps (the machine periodically uses the RTC to wake itself up and keep network services running i.e. bonjour sleep proxy).

[Blah101]

Worked great. I moved my AppleRTC kext to the E/E and ran the patch. Thanks!

[jhrfc]

Hi,
Strangley none of these fix CMOS reset after sleep for me.
I patched the AppleRTC in place on the seperate drive I've installed 10.8 onto. rebuilt caches etc, but still get a cmos reset.
These patches have worked fine for me in Lion. Hmm.
Jon

[jhrfc]

jhrfc, on 04 March 2012 - 01:28 PM, said:

Hi,
Strangley none of these fix CMOS reset after sleep for me.
I patched the AppleRTC in place on the seperate drive I've installed 10.8 onto. rebuilt caches etc, but still get a cmos reset.
These patches have worked fine for me in Lion. Hmm.
Jon

works now, I don't think I rebuilt the caches properly first time.
Thanks
Jon

[rayap]

Seems like the patch in the Opening Post is working for AppleRTC.kext in DP2 and further the kext is now half-weight as it appears purged of 32-bit code.

[rayap]

John Cash, on 22 March 2012 - 06:43 PM, said:

A few days ago when I installed DP-2 I spent some time trying to get the Opening Post patch to work reliably with the DP-2 kext but it never worked for more than one sleep/awake cycle. I gave up and used the patched DP-1 kext. After reading your post I tried again several times but no joy...

Cycled thro 'Total Sleep/Wakes since boot:4' and rebooted without problems.

[kdtt]

Patch works fine in ML dp2 p5k plain.
Before patching, when restart  in lion, cmos reset. because fsb went up ridiculously.
This time in ML, it didn't make cmos reset. but it lowered the fsb from 333 to 280.

[rayap]

Again, it seems like the patch in the Opening Post is working for AppleRTC.kext in DP3. The size of the AppleRTC exec file remains at 66,320 bytes and probably not changed.
Rgds

[blackosx]

rayap, on 22 April 2012 - 04:48 AM, said:

Again, it seems like the patch in the Opening Post is working for AppleRTC.kext in DP3.

Unless I'm mistaken, or have forgotten about some other patch I've applied somewhere, I no longer need to patch the AppleRTC binary for 10.8 DP3. Rebooting after a sleep/wake cycle now performs normally without any CMOS error.

Can somebody else check this on their setup?

[STLVNUB]

New "Tool" to hopefully eliminate this bug.
CloverRTCTool
run rc.local from CloverRTCTool folder and it will:
Install rc.local to /etc/rc.local and /etc/rc.shutdown.local
Install cmosDumperForOsx to /usr/local/bin to do RTC cmos dumps at logon and shutdown.
One size fits all

In my effort to finally track down the cmos reset bug this tool WILL come in handy.
Already these values get changed
RTC len 2
Probable CMOS RESET: Check offsets: 46 61 83 88 89 95 125
and for RTC len 4
Probable CMOS RESET: Check offsets: 46 61 83 88 89 95 125 141
These offsets are for MY motherboard GigaByte P35C-DS3R
Your offsets may be different.

To Test:
1.
run rc.local from CloverRTCTool folder and you will get the cmos dump in CloverRTCTool/CloverRTCTool
named RTCDump_0816_07-05-2012_rc.local_128.txt
0816=HourMin
07-05-2012=DMY
rc.local=will change to rc.shutdown.local
128=len 2 128 bytes, will cjhange to 256 ( or 512 eventually)
len 2 is automatically determined but doesn't seem to work properly at moment.
Particularly when run from /etc/rc.local ( run at startup), len 4 is detected as len 2.
When run from CloverRTCTool len 2/4 are correct.

2.
To Test Sleep:
Put Mac to sleep, wake it and run 1 again.
Do a compare of the two files and check if offsets above match.

3.
If you run with len 2 in RTC, try len 4 and re-run Test,

4.
This tip from RevoGirl (hi Sam)
put in kernel args rtc=7 and you also get RTC dump in kernel log.

Lets finally crack this bug