485 replies to this topic

[rcork]

After applying this patch everything is back to normal (no CMOS reset, sleep working as before). I have a BD-ROM drive that prevents auto sleep without a disc in it so i always keep a dummy CD in the drive.

GA-EP45-DS3R
Core 2 Quad Q6600
NVidia 8800GT 512MB

[longtom]

It seems that it works on P55 Mobos, but not on SandyBridge.
Sleep problem topic here: WakeUp the Lion from Sleep

Javimdq, on Jul 6 2011, 01:05 PM, said:

Where did you find this kext?

Yes, where to get it?

stevekicks, on Jul 6 2011, 02:13 PM, said:

Got my sleep working perfectly on my ga-p55a-ud3r with dsdt from tonymacs database.

Simply had to run the patch from this thread and enable "Startup automatically after a power failure" in energy settings.

Beautiful!

Not for Gigabyte Z68X Mobo!

[Iseeutoo]

Taruga, on Jul 6 2011, 10:48 AM, said:

Tested the RTC patch on an Asus P5QC and now Sleep and Wake works fine. I can even wake my pc by left clicking my mouse button. Later today I'm also going to test on my Gigabyte X38-DS5

Attached is my dsdt for the P5QC

P5Q Deluxe here. My RTC Section looks same except device names.

Device (RTC0)
				{
					Name (_HID, EisaId ("PNP0B00"))
					Name (_CRS, ResourceTemplate ()
					{
						IO (Decode16,
							0x0070,			 // Range Minimum
							0x0070,			 // Range Maximum
							0x00,			   // Alignment
							0x02,			   // Length
							)
					})
				}

AutoSleep, S3 Sleep also Wake works OOB but under 10.7 GM CMOS Reset when wake by keyboard!!! Its very important coz when i wake my HA by power button all is okay. I mean system Wakes at once without CMOS Reset.

[tseug]

Which patch did you use?

[Iseeutoo]

tseug, on Jul 6 2011, 04:18 PM, said:

Which patch did you use?

Patch? nah I'm still w8in for DSDT Solution. Kexts etc its na for me.

Just posted info about my mobo coz it could be helpful, aint it? ;- )

[bcc9]

Ok, I've taken a look at the code now.

In 10.6, checksuming occurs via the tracepoint handler code, which is only enabled if the RTC portion of the CMOS is 256 bytes or longer.  So the DSDT change where you set the RTC device's length to 2 (128 bytes) avoids the problem.

In 10.7, the tracepoint code is now *also* triggered by AppleRTC::setAlarmEnable(), even when the RTC CMOS is just 128 bytes, so the problem persists.

The patch makes skipping of the call to AppleRTC::updateChecksum() from the tracepoint code unconditional.  Since the checksuming code is doing nothing else, this appears to be a safe patch.

There's no obvious value (such as in the dsdt) to set to cause the checksum to be skipped without patching the rtcRecordTracePoint() call, as was done by the patch.

On the other hand, the tracepoints are only happening when AppleRTC::setAlarmEnable() is called with certain magic values and I'm not seeing where those calls are being made.  Presumably these are triggered by the PM code in the kernel and wouldn't be safe to alter.

[blackosx]

Thanks for passing your eye over the problem and the current solution here bcc9. I was thinking before that if anybody involved in this topic could find an alternate solution to patching the AppleRTC binary then it might be either you or cartri.

bcc9, on Jul 6 2011, 06:15 PM, said:

On the other hand, the tracepoints are only happening when AppleRTC::setAlarmEnable() is called with certain magic values and I'm not seeing where those calls are being made.  Presumably these are triggered by the PM code in the kernel and wouldn't be safe to alter.

So maybe a possible area for further research? though taking heed of your last note, better to just leave alone.

[tseug]

bcc9, on Jul 6 2011, 05:15 PM, said:

Ok, I've taken a look at the code now.

In 10.6, checksuming occurs via the tracepoint handler code, which is only enabled if the RTC portion of the CMOS is 256 bytes or longer.  So the DSDT change where you set the RTC device's length to 2 (128 bytes) avoids the problem.

In 10.7, the tracepoint code is now *also* triggered by AppleRTC::setAlarmEnable(), even when the RTC CMOS is just 128 bytes, so the problem persists.

The patch makes skipping of the call to AppleRTC::updateChecksum() from the tracepoint code unconditional.  Since the checksuming code is doing nothing else, this appears to be a safe patch.

There's no obvious value (such as in the dsdt) to set to cause the checksum to be skipped without patching the rtcRecordTracePoint() call, as was done by the patch.

On the other hand, the tracepoints are only happening when AppleRTC::setAlarmEnable() is called with certain magic values and I'm not seeing where those calls are being made.  Presumably these are triggered by the PM code in the kernel and wouldn't be safe to alter.

In case you missed it: http://www.insanelym...p...t&p=1701654

The interesting questions IMHO are: What does recordTracePoint actually do, and why would it need to recalculate the CMOS checksum? Why does it look like it's writing to offset 58,59 when it's actually writing to 2e, 2f? Why is the result of updateChecksum off by one and is that true in general?

It simply doesn't make any sense to me.

[bcc9]

tseug, on Jul 6 2011, 03:13 PM, said:

In case you missed it: http://www.insanelym...p...t&p=1701654

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.

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.
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.
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.
Why is the result of updateChecksum off by one
Where do you see it being off by 1?

blackosx, on Jul 6 2011, 11:45 AM, said:

Thanks for passing your eye over the problem and the current solution here bcc9. I was thinking before that if anybody involved in this topic could find an alternate solution to patching the AppleRTC binary then it might be either you or cartri.


So maybe a possible area for further research? though taking heed of your last note, better to just leave alone.

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.

[karaakeha1]

Javimdq, on Jul 6 2011, 07:05 AM, said:

Where did you find this kext?

this is just the old kext at kexts.com
for On board network card  RealtekR1000Lion.kext.zip   65.78K   38 downloads

[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]

bcc9, on Jul 6 2011, 11:53 PM, said:

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

Quote

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.

Quote

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.

Quote

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.

Quote

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]

bcc9, on Jul 6 2011, 11:53 PM, said:

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]

tseug, on Jul 7 2011, 04:04 AM, said:

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.

blackosx, on Jul 7 2011, 01:43 PM, said:

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.

LatinMcG, on Jul 7 2011, 02:07 PM, said:

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]

cartri, on Jul 7 2011, 07:54 PM, said:

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]

tseug, on Jul 7 2011, 05:13 PM, said:

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]

tseug, on Jul 7 2011, 12:04 AM, said:

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

tseug, on Jul 7 2011, 12:04 AM, said:

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.

blackosx, on Jul 7 2011, 09:43 AM, said:

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

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

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.

tseug, on Jul 7 2011, 12:04 AM, said:

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.

tseug, on Jul 7 2011, 12:04 AM, said:

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.