485 replies to this topic

[rayap]

bcc9, on Jul 8 2011, 01:18 AM, said:

For my nvidia mcp79 based system, I was able to fix the bios reported CMOS checksum error by making updateChecksum() return without updating anything.  The lion GM patch that only skips the updateChecksum() call from rtcRecordTracePoint() was insufficient in my case.

In my case using an unconditional jump over the rtcWrites within updateChecksum proc and is ok the last couple of weeks.

Anyway, with the heavyweights around I dread to add my two cents worth.

Nevertheless better to put it out. With a RTC register length of 0x02 nothing seems to be disturbed in the CMOS memory map. When the RTC register length is set to 0x04, we can read some values in 0x58 & 0x59 of the CMOS memory map, but 0x2e & 0x2f remains as before. These changes would appear to occur at startup. Subsequently with every sleep and wake before reboot, 0x2e is reduced by one, invalidating the real CMOS checksum.
However, even without any sleep/wake before reboot, with a RTC register length of 0x04 and with 0x2e & 0x2f unchanged but 0x58 & 0x59 populated, a CMOS Checksum error occurs at reboot. So it seems the CMOS memory map Checksum is updated at shutdown or just before reboot. Tried my hand to modify DumpCMOS.kext to write zeros to 0x58 & ox59 in the CMOS memory map, to test but failed to alter them.

Hence I would surmise that AppleRTC writes to some global memory area from where, these and others like RTC Alarms are reevaluated and written to the CMOS memory map when the system starts or stops by another agent - maybe the kernel itself or other.

Wonder if real intel-Macs have a 'CMOS memory map' and whether similar changes occur at those affected addresses. Haven't figured out what those values at 0x58 & 0x59 represent.

[nexus77777]

fredouille, on Jul 7 2011, 06:49 AM, said:

Hello
I confirm that rtc patch prevents clearbios after sleep for P35 DS4 and EP45DS3 ( don't know if it's normal & important but had to use sudo -s in shell before applying patch)
out of topic : i didn't use like karaakeha 1 realtekR1000Lion.kext but IONetworkingFamily.kext from SL for ethernet
out of topic 2 : for auto-sleep I used RIP2 (added in system preference, users and groups)

Thank you to authors of this found
fred

Will try this too...what's RIP2 ??? Merci aux Grolandais....

[tseug]

bcc9, on Jul 8 2011, 12:53 AM, said:

Sure, time permitting.  However I did only look at the code related to your patch, not everything, so I didn't mean to give the impression that I understand everything.
Also I've found that your patch doesn't work on my laptop (nvidia mcp79 chipset) so apparently I don't yet understand enough

That's interesting. What does the CMOS look like?

Quote

Did you find where offsets 2e&2f are being written and why do you keep calling those offsets checksum bytes?  AppleRTC::updateChecksum() only calls AppleRTC::rtcWrite() with offsets 0x58 & 0x59, so those are the checksum bytes for Apple hardware.

Offset 2e and 2f are checksum bytes and the reason the checksum error occur on reboot. I know they've changed because I've checked the contents of the CMOS before and after wakeup. The weird part is that with updateChecksum removed, 2e, 2f is not written to.

See http://www.codepedia.com/1/CMOS_C for a CMOS specification.

rayap, on Jul 8 2011, 03:34 AM, said:

In my case using an unconditional jump over the rtcWrites within updateChecksum proc and is ok the last couple of weeks.

Anyway, with the heavyweights around I dread to add my two cents worth.

Nevertheless better to put it out. With a RTC register length of 0x02 nothing seems to be disturbed in the CMOS memory map. When the RTC register length is set to 0x04, we can read some values in 0x58 & 0x59 of the CMOS memory map, but 0x2e & 0x2f remains as before. These changes would appear to occur at startup. Subsequently with every sleep and wake before reboot, 0x2e is reduced by one, invalidating the real CMOS checksum.
However, even without any sleep/wake before reboot, with a RTC register length of 0x04 and with 0x2e & 0x2f unchanged but 0x58 & 0x59 populated, a CMOS Checksum error occurs at reboot. So it seems the CMOS memory map Checksum is updated at shutdown or just before reboot. Tried my hand to modify DumpCMOS.kext to write zeros to 0x58 & ox59 in the CMOS memory map, to test but failed to alter them

I was thinking of doing something similar. That is to write to 0000 to offset 2e, 2f before sleep to see if both byte are being overwritten or just 2e. I just don't have the time right now, but I'll do it at some point unless somebody beats me to it.

I don't think there is any public information on what 58, 59 represents.

[tseug]

cartri, on Jul 7 2011, 09:39 PM, said:

BTW, its possible to update your Kext to make it dump all ports, one by one from 70 till 77?

Yes. I'm a bit strapped for time right now but later I can do it. Anyone with a bit of programming experience should be able to, though.

Quote

Are you based on bundled ichs in the north bridge (like p55) or separate ones like ich10?

[yonika]

Hey guys,

I need your help, I have LION GM installed with the patch to prevent CMOS reset.
After installing the patch there are not more CMOS resets. which is good.

But I do have another problem (regardless of the patch) - Every time I sleep my system, then wake it up
and then try to restart i get a kernel panic, there is no informative information such as a problematic kext or a process that was running during the panic time.

If I don't sleep the system, restart/shutdown works well.
I did try running KextUtility to fix permissions but no success.

Additional info:
1. After sleep I get a black screen and I have to press Power again to have graphics.
2. Using chameleon 2 RC5
3. mobo - gigabyte EP45T-DS3R.

I know that this thread is about CMOS RESETS problem and not SLEEP problems, but I thought it might be related, and if not, maybe someone had this issue fixed and can shed some light on it for me.

Thanks in advance,
Jonathan

[fredouille]

nexus77777, on Jul 8 2011, 06:19 AM, said:

Will try this too...what's RIP2 ??? Merci aux Grolandais....

hello
look this topic : http://www.insanelym...p...535&hl=rip3

salut et ... banzaï !

[nissefar]

yonika, on Jul 8 2011, 04:48 PM, said:

Hey guys,

I need your help, I have LION GM installed with the patch to prevent CMOS reset.
After installing the patch there are not more CMOS resets. which is good.

But I do have another problem (regardless of the patch) - Every time I sleep my system, then wake it up
and then try to restart i get a kernel panic, there is no informative information such as a problematic kext or a process that was running during the panic time.

If I don't sleep the system, restart/shutdown works well.
I did try running KextUtility to fix permissions but no success.

Additional info:
1. After sleep I get a black screen and I have to press Power again to have graphics.
2. Using chameleon 2 RC5
3. mobo - gigabyte EP45T-DS3R.

I know that this thread is about CMOS RESETS problem and not SLEEP problems, but I thought it might be related, and if not, maybe someone had this issue fixed and can shed some light on it for me.

Thanks in advance,
Jonathan

You have the same problem mentioned here:

http://www.insanelym...p...t&p=1709860

and here:

http://www.insanelym...p;#entry1709675

Lots of people have it. Wake works by USB keyboard mouse, not by power button/WoL.

In the console it says "kernel: Wake reason: ?".

No solution currently exists. Systems with the problem do have correct DSDT patches from Auto Patcher etc.

[tseug]

I've looked a bit further into the checksum problem. It turns out that offset 2f isn't written at all. Offset 2e is always decremented by one. This means that it isn't some sort of faulty checksum algorithm. I can only speculate that updateChecksum somehow causes this to happen but it seems unlikely that it writes there on its own.

I'll make a DumpCMOS that dumps the ports above 70/71 as well one of these days.


EDIT: I think I've figured out what the problem is. According to the original DSDT, Gigabyte uses the port range 70h-73h for CMOS data. For reasons having to do with non-maskable interrupts that gives you 127 + 255 bytes of CMOS. Apple uses 70h-77h which should give 127 + 255 + 255 + 255 bytes of CMOS.

I've taken a look at what my motherboard returns on 74/75 and 76/77. I turns out that it mirrors 70/71 and 72/73. In theory (I haven't tested it) that would mean that if you write to offset 2e on port 74/75 on my motherboard it would overwrite the checksum byte on offset 2e in 70/71 which will be bad On the other hand an entirely different byte will be written to on an Apple computer.

I need to write some code to test this but it's a close to a good guess as I've come.

If correct, that would mean that a motherboard with the same amount of CMOS as an Apple computer may not have a problem with CMOS resets.

EDIT EDIT: This turns out to be true on my macbook; 70/71 and 74/75 does not return the same bytes. Offset 2e isn't decremented but this is probably still the cause of the problem. If it is possible to write protect 74/75 or make a buffer for these ports in the DSDT that might solve the problem.

[bcc9]

rayap, on Jul 7 2011, 07:34 PM, said:

In my case using an unconditional jump over the rtcWrites within updateChecksum proc and is ok the last couple of weeks.

Yes, cool, that would be the safest/most easily verifiable patch, though the rest of updateChecksum() is pretty easy to read and no-oping the entire routine should be safe too IMO.
Would be good for post #1 to be updated as the GM patch referenced there doesn't work for some cases and left me having to roll my own.

rayap, on Jul 7 2011, 07:34 PM, said:

Hence I would surmise that AppleRTC writes to some global memory area from where, these and others like RTC Alarms are reevaluated and written to the CMOS memory map when the system starts or stops by another agent - maybe the kernel itself or other.

AppleSMC logs the sleep reason in smcPublishSleepCause() so I'd start looking there if you want.

rayap, on Jul 7 2011, 07:34 PM, said:

Wonder if real intel-Macs have a 'CMOS memory map' and whether similar changes occur at those affected addresses. Haven't figured out what those values at 0x58 & 0x59 represent.

I think I'm just repeating myself, but those offsets are the Apple checksum, as defined by AppleRTC::updateChecksum().  You can see that the value written there is the XOR sum that updateChecksum() computes from reading a block of CMOS bytes.

[bcc9]

tseug, on Jul 8 2011, 12:22 AM, said:

Offset 2e and 2f are checksum bytes and the reason the checksum error occur on reboot. I know they've changed because I've checked the contents of the CMOS before and after wakeup. The weird part is that with updateChecksum removed, 2e, 2f is not written to.

See http://www.codepedia.com/1/CMOS_C for a CMOS specification.



I was thinking of doing something similar. That is to write to 0000 to offset 2e, 2f before sleep to see if both byte are being overwritten or just 2e. I just don't have the time right now, but I'll do it at some point unless somebody beats me to it.

I don't think there is any public information on what 58, 59 represents.

Per here: http://wiki.osdev.org/CMOS
the checksum location is BIOS-specific.  It's pretty clear that bytes 0x58&59 are apple's checksum location (or one of several).
You seem to just want to argue with me (you didn't answer my questions and discount my answers at least).  I'm really only interested in seeing if there is a lower level fix than patching AppleRTC, as it's not very fun to maintain binary patches for every OSX release...

[rayap]

bcc9, on Jul 9 2011, 01:25 AM, said:

I think I'm just repeating myself, but those offsets are the Apple checksum, as defined by AppleRTC::updateChecksum().

Agreed. But, the Hacintosh PC causes a CMOS error early in BIOS boot process when - "2Eh and 2Fh are as defined by the original IBM PC/AT specification and represent a byte-wise additive sum of the values in locations 10h-2Dh only"- don't measure up.
This PC Checksum Error is not caused by what's in 58h or 59h or other, unless of course OSX had manipulated 2eh and/or 2fh at shutdown. We can see it does disturb 2eh on Sleep. And, in both cases there is no change in locations 10h-2Dh, thus the PC CMOS Checksum should have remained intact.

I guess that's where the divergence is, I hope.

[bcc9]

rayap, on Jul 8 2011, 08:52 PM, said:

Agreed. But, the Hacintosh PC causes a CMOS error early in BIOS boot process when - "2Eh and 2Fh are as defined by the original IBM PC/AT specification and represent a byte-wise additive sum of the values in locations 10h-2Dh only"- don't measure up.
This PC Checksum Error is not caused by what's in 58h or 59h or other, unless of course OSX had manipulated 2eh and/or 2fh at shutdown. We can see it does disturb 2eh on Sleep. And, in both cases there is no change in locations 10h-2Dh, thus the PC CMOS Checksum should have remained intact.

I guess that's where the divergence is, I hope.

Maybe the checksum that a modern PC bios typically stores @0x2e&2f actually includes offsets 0x58&0x59 in the sum.  That would seem to explain the observed behavior.  Nobody has checked (which bytes the bios is actually covering in the checksum and whether 0x2e/0x2f are being set by OSX)?

[yonika]

nissefar, on Jul 8 2011, 05:30 PM, said:

You have the same problem mentioned here:

http://www.insanelym...p...t&p=1709860

and here:

http://www.insanelym...p;#entry1709675

Lots of people have it. Wake works by USB keyboard mouse, not by power button/WoL.

In the console it says "kernel: Wake reason: ?".

No solution currently exists. Systems with the problem do have correct DSDT patches from Auto Patcher etc.

Hi and thanks,

I know that the black screen upon wake is a known issue,
However the issue that I'm looking into solving is the fact that
Once my system goes to sleep and then wake, the following restart/shutdown would kernel panic.
The black screen issue was just to add more information cause I thought it might be related.

Does any one have an enlightenment on this issue ??

Thanks in advance
Jonathan

Although it

[rayap]

@yonika
In your earlier post (#327) you indicated it happens regardless of the AppleRTC patch. So your solutions lie elsewhere. Have your dsdt checked and are you still on 10.6.1 other than Lion GM. Goodluck.

[tseug]

bcc9, on Jul 9 2011, 04:06 AM, said:

Maybe the checksum that a modern PC bios typically stores @0x2e&2f actually includes offsets 0x58&0x59 in the sum.  That would seem to explain the observed behavior.  Nobody has checked (which bytes the bios is actually covering in the checksum and whether 0x2e/0x2f are being set by OSX)?

See post #195

There are a number of checksums in a CMOS but of course the interesting one in this case is offset 2eh/2fh at port 70h/71h. This is a legacy checksum from many years ago to make PCs compatible with IBM PC. The checksum is also present at my macbook which was one of the first things I checked when I made the dump program.

The reason I can fairly confidently say that it is also a checksum on my mac is that it contains the sum of all bytes from offset 10h to offset 2dh. It don't really want to overwrite them to see what the macbook does

It is entirely reasonable to assume that 0x58 0x59 is also a checksum on a mac but the problem is not that it's a checksum but that when it is changed in updateCMOS, it somehow causes 2e to be decremented on some (if not all) PCs which invalidates the checksum on a PC. I'm fairly certain that the reason 58/59 changes on each sleep is related to the fact fact that on my machine port 74h/75h and port 70h/71h behave the same way whereas this is not the case on my macbook. Maybe it includes the real time clock in the checksum because it can read it from port 74h?

On my macbook the 2e byte is not decremented and 58/59 does not change on each sleep.

bcc9, on Jul 9 2011, 02:18 AM, said:

You seem to just want to argue with me (you didn't answer my questions and discount my answers at least).  I'm really only interested in seeing if there is a lower level fix than patching AppleRTC, as it's not very fun to maintain binary patches for every OSX release...

I don't want to argue with you. I would prefer to work together to find a real solution. If there are any questions you  
have that I haven't answered I must have missed them. Could you please repeat them? I'll be sure to answer them this time.

Anyway, that's all I have to say on this subject. Anyone can validate the above with the CMOS dumper if they feel the need to.

[yonika]

rayap, on Jul 9 2011, 04:01 AM, said:

@yonika
In your earlier post (#327) you indicated it happens regardless of the AppleRTC patch. So your solutions lie elsewhere. Have your dsdt checked and are you still on 10.6.1 other than Lion GM. Goodluck.

The fact that it happens regardless of the patch does not mean that my problem is not related !!!
The source to my problem could be the same, the AppleRTC kext.

Does anyone else have the same problem ? Kernel panics with restart/shutdown after system wake ?
Thanks In advance.
Jonathan

[nexus77777]

fredouille, on Jul 8 2011, 08:22 PM, said:

hello
look this topic : http://www.insanelym...p...535&hl=rip3

salut et ... banzaï !

Ah ah, never heard about this script ... cause I had sleep issues with some optical drive in the past...
since I bought some AD-72xxx which are more "compatible" ...

will try this too... with some f*****g Sata Pioneer DVR-216 which could not sleep nor eject empty dvd after wake...

Merci  a toi !!!

Et BANZzzaaaaîîîîîîîîîîîî !

[rayap]

This is an alternate patch for Vanilla AppleRTC.kext of Lion GM. An unconditional jump over the rtcWrites() in updateChecksum() to prevent CMOS Resets.

sudo perl -pi -e 's|\x75\x30\x44\x89\xf8|\xeb\x30\x44\x89\xf8|; s|\x75\x3d\x8b\x75\x08|\xeb\x3d\x8b\x75\x08|' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

[nexus77777]

rayap, on Jul 10 2011, 08:14 AM, said:

This is an alternate patch for Vanilla AppleRTC.kext of Lion GM. An unconditional jump over the rtcWrites() in updateChecksum() to prevent CMOS Resets.

sudo perl -pi -e 's|\x75\x30\x44\x89\xf8|\xeb\x30\x44\x89\xf8|; s|\x75\x3d\x8b\x75\x08|\xeb\x3d\x8b\x75\x08|' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

Well, thanks will try this too ...

Pm log shows this for regular autosleep of course:

Quote

Domain: applicationresponse.slowresponse
- Message: PMConnection mDNSResponder com.apple.powermanagement.applicationresponse.slowresponse 15995 ms
- Time: 06/07/11 04:47:45 HAEC  
- Signature: mDNSResponder
- UUID: D1585246-8ED8-4F7D-85ED-04F1F9DE29B2
- Result: Noop
- Response time (ms): 15995

* Domain: wake
- Message: Wake: Success - AC - UHC6
- Time: 06/07/11 05:54:05 HAEC  
- Signature: Success
- UUID: D1585246-8ED8-4F7D-85ED-04F1F9DE29B2
- Result: Success

* Domain: applicationresponse.slowresponse
- Message: Kernel powerd com.apple.powermanagement.applicationresponse.slowresponse 16003 ms
- Time: 06/07/11 05:54:05 HAEC  
- Signature: powerd
- UUID: D1585246-8ED8-4F7D-85ED-04F1F9DE29B2
- Result: Noop
- Response time (ms): 16003

* Domain: sleep
- Message: Sleep: Success - AC - Software Sleep
- Time: 09/07/11 21:52:47 HAEC  
- Signature: Success
- UUID: 5FE06ABC-025C-4AB5-9860-6C6D1FDC6A95
- Result: Success
- Sleep count : 0

* Domain: wake
- Message: Wake: Success - AC - UHC6
- Time: 09/07/11 21:53:03 HAEC  
- Signature: Success
- UUID: 5FE06ABC-025C-4AB5-9860-6C6D1FDC6A95
- Result: Success

* Domain: applicationresponse.slowresponse
- Message: PMConnection opendirectoryd com.apple.powermanagement.applicationresponse.slowresponse 150 ms
- Time: 09/07/11 21:53:03 HAEC  
- Signature: opendirectoryd
- UUID: 5FE06ABC-025C-4AB5-9860-6C6D1FDC6A95
- Result: Noop
- Response time (ms): 150

* Domain: applicationresponse.slowresponse
- Message: PMConnection SystemUIServer com.apple.powermanagement.applicationresponse.slowresponse 150 ms
- Time: 09/07/11 21:53:03 HAEC  
- Signature: SystemUIServer
- UUID: 5FE06ABC-025C-4AB5-9860-6C6D1FDC6A95
- Result: Noop
- Response time (ms): 150

* Domain: applicationresponse.slowresponse
- Message: PMConnection mDNSResponder com.apple.powermanagement.applicationresponse.slowresponse 150 ms
- Time: 09/07/11 21:53:03 HAEC  
- Signature: mDNSResponder
- UUID: 5FE06ABC-025C-4AB5-9860-6C6D1FDC6A95
- Result: Noop
- Response time (ms): 150

* Domain: applicationresponse.slowresponse
- Message: PMConnection AirPort configd plug-in com.apple.powermanagement.applicationresponse.slowresponse 216 ms
- Time: 09/07/11 21:53:03 HAEC  
- Signature: AirPort configd plug-in
- UUID: 5FE06ABC-025C-4AB5-9860-6C6D1FDC6A95
- Result: Noop
- Response time (ms): 216

* Domain: applicationresponse.slowresponse
- Message: PMConnection IPConfiguration com.apple.powermanagement.applicationresponse.slowresponse 217 ms
- Time: 09/07/11 21:53:03 HAEC  
- Signature: IPConfiguration
- UUID: 5FE06ABC-025C-4AB5-9860-6C6D1FDC6A95
- Result: Noop
- Response time (ms): 217

* Domain: sleep
- Message: Sleep: Success - AC - Software Sleep
- Time: 10/07/11 08:16:19 HAEC  
- Signature: Success
- UUID: 7A416434-F88B-46F8-A12F-57CDD5BA3253
- Result: Success
- Sleep count : 0

* Domain: sleep
- Message: Sleep: Success - AC - Idle Sleep
- Time: 10/07/11 09:09:57 HAEC  
- Signature: Success
- UUID: C2247CEF-39BD-4E52-B10A-0BBC10E683AA
- Result: Success
- Sleep count : 0

* Domain: sleep
- Message: Sleep: Success - AC - Idle Sleep
- Time: 10/07/11 09:43:48 HAEC  
- Signature: Success
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Success
- Sleep count : 0

* Domain: sleep
- Message: Sleep: Success - AC - Maintenance Sleep
- Time: 10/07/11 11:43:56 HAEC  
- Signature: Success
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Success
- Sleep count : 1

* Domain: applicationresponse.slowresponse
- Message: PMConnection mDNSResponder com.apple.powermanagement.applicationresponse.slowresponse 15989 ms
- Time: 10/07/11 11:44:12 HAEC  
- Signature: mDNSResponder
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Noop
- Response time (ms): 15989

* Domain: sleep
- Message: Sleep: Success - AC - Maintenance Sleep
- Time: 10/07/11 13:44:19 HAEC  
- Signature: Success
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Success
- Sleep count : 2

* Domain: applicationresponse.slowresponse
- Message: PMConnection mDNSResponder com.apple.powermanagement.applicationresponse.slowresponse 15996 ms
- Time: 10/07/11 13:44:35 HAEC  
- Signature: mDNSResponder
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Noop
- Response time (ms): 15996

* Domain: sleep
- Message: Sleep: Success - AC - Maintenance Sleep
- Time: 10/07/11 15:44:42 HAEC  
- Signature: Success
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Success
- Sleep count : 3

* Domain: applicationresponse.slowresponse
- Message: PMConnection mDNSResponder com.apple.powermanagement.applicationresponse.slowresponse 15996 ms
- Time: 10/07/11 15:44:58 HAEC  
- Signature: mDNSResponder
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Noop
- Response time (ms): 15996

* Domain: wake
- Message: Wake: Success - AC - Network
- Time: 10/07/11 16:09:20 HAEC  
- Signature: Success
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Success

* Domain: applicationresponse.slowresponse
- Message: Kernel powerd com.apple.powermanagement.applicationresponse.slowresponse 16002 ms
- Time: 10/07/11 16:09:20 HAEC  
- Signature: powerd
- UUID: 4983F147-BF99-4856-AC94-A5D733238083
- Result: Noop
- Response time (ms): 16002

ANy clue ???

[Rackers]

Can anybody explain to me how I can patch AppleRTC.kext or upload one ready to go?

Thanks