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

[fredouille]

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

[tseug]

Yes, I had seen that, and I asked for more info so as to avoid re-discovering what was known, but you just said that the underlying code was not understood.

 

So I've looked into the underlying code and now I think I understand , and have also documented what's going on at a higher level.

 

Great! Then you can explain it to me

 

What does recordTracePoint actually do

Recordtracepoint is recording trace information about hibernate/suspend, such as the reason for suspending, and the thread that initiated it.

 

OK.

 

why would it need to recalculate the CMOS checksum?

Since the trace information is written to CMOS, apple wants to update their checksum after writing the trace information.

 

Although that would seem to make sense the overwritten checksum (in offset 2e, 2f) only corresponds to a subset of the CMOS. None of the values in that subset has anything to do with hibernate/sleep information. It would be a rather exotic choice to write nonstandard information in this area just for the hell of it, and indeed the values are the same before and after sleep. The patch only stops AppleRTC from updating the checksum so if something was actually written in the area there ought to be a checksum error. Since there isn't and DumpCMOS isn't showing any differences in this area it seems unlikely.

 

Why does it look like it's writing to offset 58,59 when it's actually writing to 2e, 2f?

? You said in post #212 that it is writing offsets 58&59.

 

It is. It is also writing to 2e, 2f although there is no reference to 2e, 2f in the code. In all the other cases I could find the value in ESI seemed to correspond with the offset, but here it doesn't.

 

Why is the result of updateChecksum off by one

Where do you see it being off by 1?

 

I used DumpCMOS from #212 and it showed the checksum in 2e, 2f to be off by one in 2e. 2f was fine though. Blackosx then did the same and got the same result. In other words, the checksum is 0x100 less than it ought to be.

[JuliusWang]

Hi guys, thanks for the patch! I confirm it works well with my GA-x58-Ud3r version 2.0 in Lion GM. My lion is sound asleep now. Thanks so much!

[blackosx]

Thanks. Currently I have this crazy idea that maybe we could define a read-only memory region via dsdt to protect the problem CMOS bytes. I haven't done anything of the sort before however....

I tried adding:

OperationRegion(CMS1, SystemCMOS, 0x80, 0x80)

to Device RTC0 in my dsdt but it made no difference.

Looking at adding something maybe not such a crazy idea and may take us in the right direction, though I'm not to good at this kind of thing either.

 

Looking at the predefined Operation Region types in ACIPspec I see there is one for CMOS, so in the case of your example would that translate to?:

OperationRegion(CMS1, CMOS, 0x80, 0x80)

 

EDIT:

Looking further at the ACPIspec, they show an example for an RTC device with ID of PNP0B00:

Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_FIX, Package(1) { EisaId ("PNP0B00") }
Name (_CRS, ResourceTemplate () {
	IO (Decode16, 0x0070, 0x0070, 0x00, 0x02, )
}
OperationRegion (CMS1, CMOS, 0, 0x40)
Field(CMS1,ByteAcc,NoLock,Preserve)
	{
		AccessAs(ByteAcc,0),
		CM00,  8,
		,256,
		CM01,  8,
		CM02,  16,
		,216,
		CM03,  8
	}
}

 

I know cartri suggest using _FIX previously, so maybe the rest of the OperationRegion part above is something that I maybe he could throw more light on? Like could something like that work?

[LatinMcG]

i wonder if adding to SSDT would help. notice in mbp31 the sata (not pata) has code in ssdt.. why ? i noticed it supersedes dsdt in another post yrs ago.

another thing. alignment. why 00 and 02 . in mbp is 01 .. in my laptop was 10.. i changed to 01.

my after sleep reboots to slow bios post i believe is related to drive detection or DMI reset but maybe it is related to this RTC

(not sure how to debug this issue)

[cartri]

Great! Then you can explain it to me

 

 

 

OK.

 

 

 

Although that would seem to make sense the overwritten checksum (in offset 2e, 2f) only corresponds to a subset of the CMOS. None of the values in that subset has anything to do with hibernate/sleep information. It would be a rather exotic choice to write nonstandard information in this area just for the hell of it, and indeed the values are the same before and after sleep. The patch only stops AppleRTC from updating the checksum so if something was actually written in the area there ought to be a checksum error. Since there isn't and DumpCMOS isn't showing any differences in this area it seems unlikely.

 

 

 

It is. It is also writing to 2e, 2f although there is no reference to 2e, 2f in the code. In all the other cases I could find the value in ESI seemed to correspond with the offset, but here it doesn't.

 

 

 

I used DumpCMOS from #212 and it showed the checksum in 2e, 2f to be off by one in 2e. 2f was fine though. Blackosx then did the same and got the same result. In other words, the checksum is 0x100 less than it ought to be.

 

You mobo has an ESI defined? Gigabyte don't define it usually, i use a customized bios to do that, but is for me cosmetic, a device tree organization, nothing else.

 

 

Looking at adding something maybe not such a crazy idea and may take us in the right direction, though I'm not to good at this kind of thing either.

 

Looking at the predefined Operation Region types in ACIPspec I see there is one for CMOS, so in the case of your example would that translate to?:

OperationRegion(CMS1, CMOS, 0x80, 0x80)

 

EDIT:

Looking further at the ACPIspec, they show an example for an RTC device with ID of PNP0B00:

Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_FIX_ Package(1) { EisaId ("PNP0B00") }
Name (_CRS, ResourceTemplate () {
	IO (Decode16, 0x0070, 0x0070, 0x00, 0x02, )
}
OperationRegion (CMS1, CMOS, 0, 0x40)
Field(CMS1,ByteAcc,NoLock,Preserve)
	{
		AccessAs(ByteAcc,0),
		CM00,  8,
		,256,
		CM01,  8,
		CM02,  16,
		,216,
		CM03,  8
	}
}

 

CMOS has been replaced by SystemCMOS (like in the code i did input earlier) in the latest versions of intel and Microsoft ACPI to avoid legacy related problems, it will depend on the version of your compiler if it will work or not, in fact CMOS has been used as a device or operation region in many mobs, thats why they changed.

 

i wonder if adding to SSDT would help. notice in mbp31 the sata (not pata) has code in ssdt.. why ? i noticed it supersedes dsdt in another post yrs ago.

another thing. alignment. why 00 and 02 . in mbp is 01 .. in my laptop was 10.. i changed to 01.

my after sleep reboots to slow bios post i believe is related to drive detection or DMI reset but maybe it is related to this RTC

(not sure how to debug this issue)

SSDTs are dynamic continuations of DSDTs, normally you have a module (or dsdt code) that calls the external defined object (like it happens with the IOU2, its' pcie switcher for ppb3 and ppb4 in ich10 based macpros, or to had-gfx checking itself). If you are not modding the bios but the after-boot (i mean, mobo boot) dsdt, it is better to insert your code with the dynamic changes inside itself.

 

----

 

Sorry again for the absence, only now i got dp4 running fine (i don't sleep anyway, neither my computer, so no problem if i still have the sleep bug) because of the led cinema display, and updating to GM is unpredictable... my installation is a mess right now, i have been checking the topic trough the iPhone mails i receive when someone posts.

 

It is interesting on this that we have SystemIO 0x74 defined in a pnp0c02 device (unfortunately gigabyte has many 0c02 devices, each one with a unique ID to differ) as something else, this can be other part of the cmos.

 

It is quite normal that the RTC (which is just a part of the CMOS, not it all) marks it's status, what is strange is doing the checksum change as Tseug showed with his kext. It is notable that our rtc has 2 different options of length, using 128 or 256bytes (length 2 or 4, being each "1" 64byte, ICH10 RTC is always organized in one or 2 banks of 128Bytes, first 64 for read last for write, like tseug showed us in the ports 70/71 for those using length 2) and each with or without the IRQ8.

Setting IRQ8 activates the STS bit.

I know i sound confuse, sorry its hard to organize technical ideas in English for me (my language has the adjectives after the substantives as so i get a little confused)

 

For reference, our RTC (ICH10) uses Motorola MC146818A-compatible rtc with 256 bytes of battery-backed RAM, it will be configured in 2 modes single (128B) or dual (256B) bank, with or without STS support (which is set by IRQ8ing it in the DSDT). It is inside the ICH10 and stores info about the clock and at what time power management events happened, resyncing the clock when the system wakes, or for supporting timed execution of some stuff, like when you set auto-sleep or auto-wake: the RTC is the responsible to know what time is it in UTC to wake your computer for instance.

 

As so, we cannot just dump the RTC full banks (256Bytes) and write it later as it was, cause time has changed and this would desync our sleep. But, we do have a RTC register in ICH10 spreadsheet that tells us:

 

10.1.73
RC—RTC Configuration Register
Offset Address: 3400–3403h Attribute: R/W, R/WLO Default Value: 00000000h Size: 32-bit
Bit
Description
31:5
Reserved
4
Upper 128 Byte Lock (UL) — R/WLO.
0 = Bytes not locked.
1 = Bytes 38h-3Fh in the upper 128-byte bank of RTC RAM are locked and cannot be
accessed. Writes will be dropped and reads will not return any ensured data. Bit reset on system reset.
3
Lower 128 Byte Lock (LL) — R/WLO.
0 = Bytes not locked.
1 = Bytes 38h-3Fh in the lower 128-byte bank of RTC RAM are locked and cannot be
accessed. Writes will be dropped and reads will not return any ensured data. Bit reset on system reset.
2
Upper 128 Byte Enable (UE) — R/W.
0 = Bytes locked.
1 = The upper 128-byte bank of RTC RAM can be accessed.
1:0
Reserved

 

With that we could lock the RTC info for the OS, what could or solve our problem or really make the system unbootable.

 

I know i did not help a lot, besides interested in the subject, i can't test it on GM as i am using a mix of video drivers to make my gpu work correctly with lion's opengl3 x3000 kext and the miniDP, and bc of this I have no wake at all, even if everything were fine with my RTC wake

[tseug]

You mobo has an ESI defined? Gigabyte don't define it usually, i use a customized bios to do that, but is for me cosmetic, a device tree organization, nothing else.

 

No, I meant the ESI register (Extended Source Index). If you look at the code in AppleRTC you'll notice that it usually corresponds to a reasonable offset value in the current context. It seems to be a reasonable assumption that it holds the CMOS offset value. That assumption breaks down when looking at the updateChecksum but it seems told hold otherwise which seems significant.

 

The question is whether updateChecksum is supposed to update 2e, 2f and does it incorrectly or if something causes the function to write in an area it shouldn't be writing in. The latter seems the most probable since there shouldn't be any reason to update that particurlar checksum (the clock stuff resides in 0x00-0x10 which isn't part of the checksum).

 

Is it possible to debug AppleRTC while it's reacting to a sleep event?

[cartri]

No, I meant the ESI register (Extended Source Index). If you look at the code in AppleRTC you'll notice that it usually corresponds to a reasonable offset value in the current context. It seems to be a reasonable assumption that it holds the CMOS offset value. That assumption breaks down when looking at the updateChecksum but it seems told hold otherwise which seems significant.

 

The question is whether updateChecksum is supposed to update 2e, 2f and does it incorrectly or if something causes the function to write in an area it shouldn't be writing in. The latter seems the most probable since there shouldn't be any reason to update that particurlar checksum (the clock stuff resides in 0x00-0x10 which isn't part of the checksum).

 

Is it possible to debug AppleRTC while it's reacting to a sleep event?

Sorry, lost in translation, i was thinking you were talking about the ESI Port, now i think you are talking about NMI / RTC_INDX , which are the 1st 7 bits of IO port 0x0074, right?

If yes, it is interesting to notice that gigabyte defines it under its LDRC (SYSR i guess, renamed long ago is the UID1 0c02 device) going from 74 with length C, finishing in 80 like our cmos. All pair registers from 70 till 76 are index and odd until 77 are targets, being the last ones extended ram registers...

Sorry, I am not really understanding what you are talking about....

BTW, its possible to update your Kext (edit: dictionary keeps renaming my "kexts" to "nexts") to make it dump all ports, one by one from 70 till 77?

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

[bcc9]

Great! Then you can explain it to me

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

Although that would seem to make sense the overwritten checksum (in offset 2e, 2f)

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.

Looking at the predefined Operation Region types in ACIPspec I see there is one for CMOS, so in the case of your example would that translate to?:

OperationRegion(CMS1, CMOS, 0x80, 0x80)

Yes, I noticed that in the spec but the intel AML compiler is expecting the keyword "SystemCMOS" which is why I wrote it that way instead. It does give me pause that none of the examples in the spec compile...

 

Sorry, lost in translation, i was thinking you were talking about the ESI Port, now i think you are talking about NMI / RTC_INDX , which are the 1st 7 bits of IO port 0x0074, right?

No, he just means the 32-bit general purpose register in intel x86 assembly language.

 

 

 

It is. It is also writing to 2e, 2f although there is no reference to 2e, 2f in the code. In all the other cases I could find the value in ESI seemed to correspond with the offset, but here it doesn't.

So it sounds like you're talking about some other bytes that are written elsewhere, such as in one of the calls to rtcWriteBytes() or rtcWriteBytesAndCRC(), which can in turn be called from user space. I'm not clear why you're asking about these if skipping the writes to 0x58 & 0x59 was a sufficient fix for your system.

 

 

None of the values in that subset has anything to do with hibernate/sleep information. It would be a rather exotic choice to write nonstandard information in this area just for the hell of it

I think you're pretty off base here - the tracepoint information is written above offset 0x80. As I mentioned before, under 10.6, the workaround of setting the CMOS memory to 128 bytes works because of the related length check.

It's not exotic to record information about why sleep&wake are occuring. sleep/wake problems are very difficult to debug otherwise (I dread trying to debug such problems under windows).

[bcc9]

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.

[rayap]

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]

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]

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?

 

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.

 

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]

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.

 

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]

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

 

hello

look this topic : http://www.insanelymac.com/forum/index.php...535&hl=rip3

 

salut et ... banzaï !

[nissefar]

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.insanelymac.com/forum/index.php...t&p=1709860

 

and here:

 

http://www.insanelymac.com/forum/index.php...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]

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.

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.

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]

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]

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]

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]

You have the same problem mentioned here:

 

http://www.insanelymac.com/forum/index.php...t&p=1709860

 

and here:

 

http://www.insanelymac.com/forum/index.php...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]

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.

 

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.