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

[Bansaku]

Of course I have the CMOS reset issue

 

I must ask though - what do you mean by "re-sleep via per button...." ??

 

thanks

Jonathan

 

What I mean is you sleep you system, and you wake it, you get everything coming back online but the display (gfx) is not waking. So, when you wake from sleep (mouse, keyboard, etc) and your display is not becoming active again, hit the power button to re-initiate sleep, since you cannot see the desktop thus is the only way to make your system sleep again. Then wake again and you should have the desktop. If the display still doesn't come back online AFTER you put the system to sleep again, try hitting the mouse button, as sometimes (for me anyway) the GFX wakes up but for some reason the monitor doesn't get the signal. The system behaves as if you simply slept the display.

[Vlada.]

Thanks for testing I was feeling alone hehe.

OK, I also make this test… and… it doesn’t work in my case too!

 

Device (RTC)
               {
                   Name (_HID, EisaId ("PNP0B00"))
                   Name (_FIX, Package (0x01)
                   {
                       0x000BD041
                   })
                   Name (_CRS, ResourceTemplate ()
                   {
                       IO (Decode16,
                           0x0070,             // Range Minimum
                           0x0070,             // Range Maximum
                           0x01,               // Alignment
                           0x04,               // Length
                           )
                   })
               }

 

There was no "RTC single ram only" reports during the boot, however I got another one: Sleep Failure Code 0xa9483225 0x39338844

 

So it was obvious that this patch won’t work, but no matter on this I put my computer in to sleep just from curiosity. Of course as expected, it didn’t work (got stuck upon wake) and after reboot I was got again CMOS reset, which is also standard expectation.

 

This is interesting idea, but obviously something missing here…

 

I will leave here my DSDT just in case, because someone might need that for comparing or testing...

DSDT_Foxconn_P35A.aml.zip

[blackosx]

I'm guessing one could add 0x100 in the DSDT somehow if the discrepancy is consistent?

I like this idea and am trying to get my head around what would be needed to accomplish it. Can the checksum byte be directly written to through ACPI as don't all writes need to go through 0x70 and 0x71? or is there a way to force the re-calculation of the checksum as the values used to calculate it aren't changed?

 

@Cartri - I've tried a combination of DSDT patches to test your theoretical solutions but have had no success with any of them. I'll keep plugging away here running tests, but maybe you could shine some light on the above idea of adding 0x100 to the checksum? I'm looking at the ICH10 datasheet, OperationRegion's in DSDT (a bit like you suggested with SMOD/INFO) but I'm not too good at this

[tseug]

Oh, the joys of lowlevel hacking

 

I've looked a bit closer on the assembly. I'll share what I found out and then I think I'll wait for a final release of Lion.

 

I've only disassembled the 64 bit part. In order to do the same, you'll need the subversion trunk of otx.

 

All snippets are from AppleRTC (obviously)

 

There are numerous rtcWrites in the code. They are situated where it makes sense such as when updating the clock would be reasonable.

 

Here's one from start:

 

+649  0000000000003419  be0b000000				movl		$0x0000000b,%esi
+654  000000000000341e  4c89f7					movq		%r14,%rdi
+657  0000000000003421  e8c0dcffff				callq	   AppleRTC::rtcWrite(unsigned int, unsigned char)

 

Comparing the writes seem to suggest that the offset is stored in ESI. In other words the above writes to Status Register B. The offsets written to also seem to make sense based on the names of the functions. Well, almost.

 

So we'll expect updateChecksum() to write to two offsets, 2E and 2F. It does indeed write to two offsets but not the ones we would think:

 

+211  0000000000002a9b  be58000000				movl		$0x00000058,%esi			  'X'
+216  0000000000002aa0  4889df					movq		%rbx,%rdi
+219  0000000000002aa3  e83ee6ffff				callq	   AppleRTC::rtcWrite(unsigned int, unsigned char)
+224  0000000000002aa8  410fb6d7				  movzbl	  %bh,%edx
+228  0000000000002aac  be59000000				movl		$0x00000059,%esi			  'Y'
+233  0000000000002ab1  4889df					movq		%rbx,%rdi
+236  0000000000002ab4  e82de6ffff				callq	   AppleRTC::rtcWrite(unsigned int, unsigned char)

 

58 and 59? It could be another internally used checksum or it could be that some sort of magic is done in rtcWrite or maybe there are some memory mapping going on - I don't know.

 

Our previously identified culprit, rtcRecordTracePoint also writes to 58,59:

 

+643  000000000000415f  be58000000				movl		$0x00000058,%esi			  'X'
+648  0000000000004164  4889df					movq		%rbx,%rdi
+651  0000000000004167  e87acfffff				callq	   AppleRTC::rtcWrite(unsigned int, unsigned char)
+656  000000000000416c  410fb6d6				  movzbl	  %dh,%edx
+660  0000000000004170  be59000000				movl		$0x00000059,%esi			  'Y'
+665  0000000000004175  4889df					movq		%rbx,%rdi
+668  0000000000004178  e869cfffff				callq	   AppleRTC::rtcWrite(unsigned int, unsigned char)
+673  000000000000417d  8b8358010000			  movl		0x00000158(%rbx),%eax
+679  0000000000004183  89835c010000			  movl		%eax,0x0000015c(%rbx)
+685  0000000000004189  488bbb90000000			movq		0x00000090(%rbx),%rdi
+692  0000000000004190  e800000000				callq	   0x00004195
+697  0000000000004195  8b7da0					movl		0xa0(%rbp),%edi
+700  0000000000004198  e800000000				callq	   0x0000419d
+705  000000000000419d  837dbc00				  cmpl		$0x00,0xbc(%rbp)
+709  00000000000041a1  7410					  je		  0x000041b3
+711  00000000000041a3  8b45b4					movl		0xb4(%rbp),%eax
+714  00000000000041a6  3945b8					cmpl		%eax,0xb8(%rbp)
+717  00000000000041a9  7408					  je		  0x000041b3
+719  00000000000041ab  4889df					movq		%rbx,%rdi
+722  00000000000041ae  e815e8ffff				callq	   AppleRTC::updateChecksum()

 

..which might (or might not) be the root of the problem. We see that it may call updateChecksum later on unless it jumps over it so the problem could also be that updateChecksum is not called.

 

I've updated DumpCMOS to also dump the rest of the CMOS above offset 10h. Indeed there are additional changes after sleep/wake on a unmodified AppleRTC

 

0x3d: 0xd1 -> 0x00

0x58: 0x00 -> 0x37

0x59: 0x00 -> 0x49

0x7d: 0x06 -> 0x06 -> 0x05

 

A few observations that may or may not be significant:

 

Offset 0x7d contains the same value as 0x2e before and after sleep. After sleep is is incorrectly off by one if we assume a correlation.

 

0xff - 0xd1 (the value in offset 0x3d before sleep) = 0x2e . Coincidence?

 

That's it for me (for now, I think).

 

DumpCMOS code:

 

#include <sys/systm.h>
#include <mach/mach_types.h>

void ReadFromCMOS (unsigned char array []) {
unsigned char tvalue, index;

for(index = 0x10; index < 0x80; index++) {
	_asm {
		cli             /* Disable interrupts*/
		mov al, index   /* Move index address*/
		/* since the 0x80 bit of al is not set, NMI is active */
		out 0x70,al     /* Copy address to CMOS register*/
		nop
		nop
		nop
		nop
		nop
		/* some kind of real delay here is probably best */
		in al,0x71      /* Fetch 1 byte to al*/
		sti             /* Enable interrupts*/
		mov tvalue,al
	}

	array[index - 0x10] = tvalue;
}
}


kern_return_t DumpCMOS_start (kmod_info_t * ki, void * d) {
unsigned char index;
unsigned char cmos[0x70];

printf("DumpCMOS has started.\n");

ReadFromCMOS(cmos);

printf("CMOS Dump:\n");

for(index = 0; index < 0x70; index++) {
	printf("%02x: %02x\n", index + 0x10, cmos[index]);
}

   return KERN_SUCCESS;
}


kern_return_t DumpCMOS_stop (kmod_info_t * ki, void * d) {
printf("DumpCMOS has stopped.\n");

   return KERN_SUCCESS;
}

 

Extended kext: DumpCMOS.zip

[blackosx]

Nice research tseug. I'll have a deeper look at it tonight.

 

With regard to function updateChecksum, I did some more tests of my own last night (replicating rayap's tests) by looking at the x86 dump from otx.

I tested blocking (replacing with nop's) the following three calls to updateChecksum:

e8f2e6ffff at offset 0x00003d3b in rtcRecordTracePoint
e8cbf9ffff at offset 0x00002a62 in setupDateTimeAlarm
e8a0eeffff at offset 0x0000358d in rtcWriteBytesAndCRC

but still noticed the checksum byte 0x2E changed after sleep/wake. So your find here of 58 and 59 will be the reason for that. Thanks

 

oh. And thanks for the updated DumpCMOS kext. I'll try it later.

 

EDIT:

As I'm at work so I thought I'd test the revised DumpCMOS kext on my iMac.

Of course, on the iMac there are no differences before and after sleep/wake, but there are differences between dumps from Snow Leopard and Lion, highlighting 58 and 59 as tseug found.

	   10.6  10.7
0x58:  0x0C  0x32
0x59:  0xD7  0xAC
0x67:  0x02  0x04

 

EDIT2:

Here's the differences from the results using the revised DumpCMOS kext on my hack with the kernel in 64-bit mode.

0x2E:	06 -> 05
0x3D:	D1 -> 00
0x58:	00 -> 15
0x59:	00 -> 95
0x5D:	20 -> 00
0x7D:	07 -> 06

 

Offset 0x7d contains the same value as 0x2e before and after sleep. After sleep is is incorrectly off by one if we assume a correlation.

In my test above 0x7d is an increment of one of 0x2e in the case of before and after sleep.

[tseug]

Nice research tseug. I'll have a deeper look at it tonight.

 

With regard to function updateChecksum, I did some more tests of my own last night (replicating rayap's tests) by looking at the x86 dump from otx.

I tested blocking (replacing with nop's) the following three calls to updateChecksum:

 

Just make sure you're actually running the x86 kernel. I played around for a while and couldn't understand why nothing was happening. Turned out I was modifying the x86 code but running the x86_64. Once I realized that I was able to achieve lots of kernel panics I'm a newbie is what I'm trying to say

 

If anyone else is running the kext would be nice if you could confirm whether the correlation between offset 0x7d and 0x3d to 0x2e actually exists or if it is just a coincidence.

 

EDIT: It turns out that changing +709 or +717 in rtcRecordTracePoint to an unconditional jump seems to resolve the issue. That is,

 

+709: 7410 -> eb10 or

+717: 7408 -> eb08.

 

That means that it's most likely updateChecksum that does something weird. Who would have guessed?

[blackosx]

Just make sure you're actually running the x86 kernel.

Yep. I was.

 

If anyone else is running the kext would be nice if you could confirm whether the correlation between offset 0x7d and 0x3d to 0x2e actually exists or if it is just a coincidence.

I added results from my hack to my post above.

 

Just make sure you're actually running the x86 kernel. I played around for a while and couldn't understand why EDIT: It turns out that changing +709 or +717 in rtcRecordTracePoint to an unconditional jump seems to resolve the issue. That is,

 

+709: 7410 -> eb10 or

+717: 7408 -> eb08.

Confirmed for 32-bit with the following: (Note: I changed both)

+765: 7413 -> eb13

+773: 7406 -> eb06

+773: 740b -> eb0b

 

That's a far simpler change than the previous patch. Well done again tseug

 

That means that it's most likely updateChecksum that does something weird. Who would have guessed?

I wonder with my tests last night blocking calls to updateChecksum that I didn't get to see any results..?

[tseug]

Yep. I was.

 

 

I added results from my hack to my post above.

 

 

Confirmed for 32-bit with the following: (Note: I changed both)

+765: 7413 -> eb13

+773: 7406 -> eb06

 

That's a far simpler change than the previous patch. Well done again tseug

 

 

I wonder with my tests last night blocking calls to updateChecksum that I didn't get to see any results..?

 

Thanks. We're still two bytes away from vanilla, though Anyway, I don't think I'll get any closer to figuring out what the real problem is, but at least it works for now. I've tried to mess around with the scheduled wake and the date time stuff but I couldn't get a CMOS reset that way and the mysteriously similar values in the upper part of the CMOS seems to be a bust as well. Hopefully someone will figure out a vanilla fix.

 

Thanks for testing and good ideas

[blackosx]

Thanks. We're still two bytes away from vanilla, though

Yeah, but it's still better than we were at.

 

Thanks for testing and good ideas

np. I enjoy it

Thanks for the research.

 

And for anyone wanting to try the latest patch, I've put it in to another terminal script. This is for both 32bit and 64bit.

sudo perl -pi -e 's|\xBC\x00\x74\x10|\xBC\x00\xEB\x10|; s|\x45\xB8\x74\x08|\x45\xB8\xEB\x08|; s|\xD0\x00\x74\x13|\xD0\x00\xEB\x13|; s|\x45\xCC\x74\x0B|\x45\xCC\xEB\x0B|;' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

Note: I have patched both jumps for each architecture but tseug did say that changing either jump would suffice - I just haven't tested that. So if that's the case then this patch can be even smaller.

PS. remember to backup your original AppleRTC.kext first.

 

Bed time now.

[oldnapalm]

The patch works here. I have an Asus P5E mobo, actually I don't know if the CMOS is reset, but I get a message about CPU configuration error after sleep/wake/restart|shutdown, with options to enter BIOS setup or continue, but the BIOS configuration is untouched (I don't use overclock, so the CPU part is default, but other configs are untouched). With this patch in AppleRTC I get no message after restart.

 

I also have an Asus N53JQ laptop which doesn't get CMOS reset or any messages after sleep/restart, I'm attaching its ACPI tables, maybe you can find something interesting.

 

acpi.tar.gz

[blackosx]

Hi oldnapalm

 

allenwkk also posted CPU messages with his Asus P6T SE. It looks like the AMI bios on the Asus boards reports the problem here in more detail than the Award bios in the Gigabyte bards.

 

Thanks for the ACPI tables.

[blackosx]

I tried some tests this morning with a modded FACP (FADT). These were to try with a different Flags value.

 

By default my Flags are set at 000004A5, which can be described with the following bits enabled:

WBINVD instruction is operational (V1) : 1

All CPUs support C1 (V1) : 1

Control Method Sleep Button (V1) : 1

RTC can wake system from S4 (V1) : 1

Reset Register Supported (V2) : 1

 

OldNapalm's FACP table has other bits also set, these are:

Docking Supported (V1) : 1

Use Platform Timer (V4) : 1

RTC_STS valid on S4 wake (V4) : 1

Remote Power-on capable (V4) : 1

 

Other differences are Oldnaplams' Revision is set to 04 where mine is set to 01, and Oldnaplams' RTC Century Index is 32 where as mine is set to 00.

 

So I changed the RTC Century Index to 32 in an extracted FACP table from my system, recompiled it, saved it as FADT.aml and added it to my /Extra folder of my test booter alongside my DSDT.aml. I then took my modded version of Valv's booter and amended it further to patch my Flags to enable some of the bits to match Oldnapalms.

 

Lastly, I added the following boot options to /Extra/com.apple.Boot.plist for Valv's booter which updates the FACP version, converts RSDT to XSDT and any other necessary things that's needed (I think).

	<key>UpdateACPI</key>
<string>Yes</string>
<key>UpdateACPIVersion</key>
<string>Yes</string>

 

This resulted in a booted FACP table looking like this:

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20110316-64 [Mar 16 2011]
* Copyright © 2000 - 2011 Intel Corporation
*
* ACPI Data Table [FACP]
*
* Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
*/

[000h 0000   4]                    Signature : "FACP"    /* Fixed ACPI Description Table */
[004h 0004   4]                 Table Length : 000000F4
[008h 0008   1]                     Revision : 04
[009h 0009   1]                     Checksum : C7
[00Ah 0010   6]                       Oem ID : "GBT   "
[010h 0016   8]                 Oem Table ID : "GBTUACPI"
[018h 0024   4]                 Oem Revision : 42302E31
[01Ch 0028   4]              Asl Compiler ID : "INTL"
[020h 0032   4]        Asl Compiler Revision : 20110316

[024h 0036   4]                 FACS Address : DFEE0000
[028h 0040   4]                 DSDT Address : 01760000
[02Ch 0044   1]                        Model : 01
[02Dh 0045   1]                   PM Profile : 03 (Workstation)
[02Eh 0046   2]                SCI Interrupt : 0009
[030h 0048   4]             SMI Command Port : 000000B2
[034h 0052   1]            ACPI Enable Value : A1
[035h 0053   1]           ACPI Disable Value : A0
[036h 0054   1]               S4BIOS Command : 00
[037h 0055   1]              P-State Control : 34
[038h 0056   4]     PM1A Event Block Address : 00000400
[03Ch 0060   4]     PM1B Event Block Address : 00000000
[040h 0064   4]   PM1A Control Block Address : 00000404
[044h 0068   4]   PM1B Control Block Address : 00000000
[048h 0072   4]    PM2 Control Block Address : 00000450
[04Ch 0076   4]       PM Timer Block Address : 00000408
[050h 0080   4]           GPE0 Block Address : 00000420
[054h 0084   4]           GPE1 Block Address : 00000000
[058h 0088   1]       PM1 Event Block Length : 04
[059h 0089   1]     PM1 Control Block Length : 02
[05Ah 0090   1]     PM2 Control Block Length : 01
[05Bh 0091   1]        PM Timer Block Length : 04
[05Ch 0092   1]            GPE0 Block Length : 10
[05Dh 0093   1]            GPE1 Block Length : 00
[05Eh 0094   1]             GPE1 Base Offset : 00
[05Fh 0095   1]                 _CST Support : 00
[060h 0096   2]                   C2 Latency : 005A
[062h 0098   2]                   C3 Latency : 0384
[064h 0100   2]               CPU Cache Size : 0000
[066h 0102   2]           Cache Flush Stride : 0000
[068h 0104   1]            Duty Cycle Offset : 01
[069h 0105   1]             Duty Cycle Width : 03
[06Ah 0106   1]          RTC Day Alarm Index : 0D
[06Bh 0107   1]        RTC Month Alarm Index : 00
[06Ch 0108   1]            RTC Century Index : 32
[06Dh 0109   2]   Boot Flags (decoded below) : 0010
              Legacy Devices Supported (V2) : 0
           8042 Present on ports 60/64 (V2) : 0
                       VGA Not Present (V4) : 0
                     MSI Not Supported (V4) : 0
               PCIe ASPM Not Supported (V4) : 1
[06Fh 0111   1]                     Reserved : 00
[070h 0112   4]        Flags (decoded below) : 000184A5
     WBINVD instruction is operational (V1) : 1
             WBINVD flushes all caches (V1) : 0
                   All CPUs support C1 (V1) : 1
                 C2 works on MP system (V1) : 0
           Control Method Power Button (V1) : 0
           Control Method Sleep Button (V1) : 1
       RTC wake not in fixed reg space (V1) : 0
           RTC can wake system from S4 (V1) : 1
                       32-bit PM Timer (V1) : 0
                     Docking Supported (V1) : 0
              Reset Register Supported (V2) : 1
                           Sealed Case (V3) : 0
                   Headless - No Video (V3) : 0
       Use native instr after SLP_TYPx (V3) : 0
             PCIEXP_WAK Bits Supported (V4) : 0
                    Use Platform Timer (V4) : 1
              RTC_STS valid on S4 wake (V4) : 1
               Remote Power-on capable (V4) : 0
                Use APIC Cluster Model (V4) : 0
    Use APIC Physical Destination Mode (V4) : 0

[074h 0116  12]               Reset Register : <Generic Address Structure>
[074h 0116   1]                     Space ID : 01 (SystemIO)
[075h 0117   1]                    Bit Width : 08
[076h 0118   1]                   Bit Offset : 00
[077h 0119   1]         Encoded Access Width : 00 (Undefined/Legacy)
[078h 0120   8]                      Address : 0000000000000CF9

[080h 0128   1]         Value to cause reset : 06
[081h 0129   3]                     Reserved : 000000
[084h 0132   8]                 FACS Address : 00000000DFEE0000
[08Ch 0140   8]                 DSDT Address : 0000000001760000
[094h 0148  12]             PM1A Event Block : <Generic Address Structure>
[094h 0148   1]                     Space ID : 01 (SystemIO)
[095h 0149   1]                    Bit Width : 20
[096h 0150   1]                   Bit Offset : 00
[097h 0151   1]         Encoded Access Width : 00 (Undefined/Legacy)
[098h 0152   8]                      Address : 0000000000000400

[0A0h 0160  12]             PM1B Event Block : <Generic Address Structure>
[0A0h 0160   1]                     Space ID : 01 (SystemIO)
[0A1h 0161   1]                    Bit Width : 00
[0A2h 0162   1]                   Bit Offset : 00
[0A3h 0163   1]         Encoded Access Width : 00 (Undefined/Legacy)
[0A4h 0164   8]                      Address : 0000000000000000

[0ACh 0172  12]           PM1A Control Block : <Generic Address Structure>
[0ACh 0172   1]                     Space ID : 01 (SystemIO)
[0ADh 0173   1]                    Bit Width : 10
[0AEh 0174   1]                   Bit Offset : 00
[0AFh 0175   1]         Encoded Access Width : 00 (Undefined/Legacy)
[0B0h 0176   8]                      Address : 0000000000000404

[0B8h 0184  12]           PM1B Control Block : <Generic Address Structure>
[0B8h 0184   1]                     Space ID : 01 (SystemIO)
[0B9h 0185   1]                    Bit Width : 00
[0BAh 0186   1]                   Bit Offset : 00
[0BBh 0187   1]         Encoded Access Width : 00 (Undefined/Legacy)
[0BCh 0188   8]                      Address : 0000000000000000

[0C4h 0196  12]            PM2 Control Block : <Generic Address Structure>
[0C4h 0196   1]                     Space ID : 01 (SystemIO)
[0C5h 0197   1]                    Bit Width : 08
[0C6h 0198   1]                   Bit Offset : 00
[0C7h 0199   1]         Encoded Access Width : 00 (Undefined/Legacy)
[0C8h 0200   8]                      Address : 0000000000000450

[0D0h 0208  12]               PM Timer Block : <Generic Address Structure>
[0D0h 0208   1]                     Space ID : 01 (SystemIO)
[0D1h 0209   1]                    Bit Width : 20
[0D2h 0210   1]                   Bit Offset : 00
[0D3h 0211   1]         Encoded Access Width : 00 (Undefined/Legacy)
[0D4h 0212   8]                      Address : 0000000000000408

[0DCh 0220  12]                   GPE0 Block : <Generic Address Structure>
[0DCh 0220   1]                     Space ID : 01 (SystemIO)
[0DDh 0221   1]                    Bit Width : 80
[0DEh 0222   1]                   Bit Offset : 00
[0DFh 0223   1]         Encoded Access Width : 00 (Undefined/Legacy)
[0E0h 0224   8]                      Address : 0000000000000420

[0E8h 0232  12]                   GPE1 Block : <Generic Address Structure>
[0E8h 0232   1]                     Space ID : 01 (SystemIO)
[0E9h 0233   1]                    Bit Width : 00
[0EAh 0234   1]                   Bit Offset : 00
[0EBh 0235   1]         Encoded Access Width : 00 (Undefined/Legacy)
[0ECh 0236   8]                      Address : 0000000000000000


Raw Table Data: Length 244 (0xF4)

 0000: 46 41 43 50 F4 00 00 00 04 C7 47 42 54 20 20 20  FACP......GBT   
 0010: 47 42 54 55 41 43 50 49 31 2E 30 42 49 4E 54 4C  GBTUACPI1.0BINTL
 0020: 16 03 11 20 00 00 EE DF 00 00 76 01 01 03 09 00  ... ......v.....
 0030: B2 00 00 00 A1 A0 00 34 00 04 00 00 00 00 00 00  .......4........
 0040: 04 04 00 00 00 00 00 00 50 04 00 00 08 04 00 00  ........P.......
 0050: 20 04 00 00 00 00 00 00 04 02 01 04 10 00 00 00   ...............
 0060: 5A 00 84 03 00 00 00 00 01 03 0D 00 32 10 00 00  Z...........2...
 0070: A5 84 01 00 01 08 00 00 F9 0C 00 00 00 00 00 00  ................
 0080: 06 00 00 00 00 00 EE DF 00 00 00 00 00 00 76 01  ..............v.
 0090: 00 00 00 00 01 20 00 00 00 04 00 00 00 00 00 00  ..... ..........
 00A0: 01 00 00 00 00 00 00 00 00 00 00 00 01 10 00 00  ................
 00B0: 04 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
 00C0: 00 00 00 00 01 08 00 00 50 04 00 00 00 00 00 00  ........P.......
 00D0: 01 20 00 00 08 04 00 00 00 00 00 00 01 80 00 00  . ..............
 00E0: 20 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00   ...............
 00F0: 00 00 00 00                                      ....

 

Unfortunately though, RTC register 0x2E is still being changed after using sleep/wake

So those changes alone are not enough to solve this conundrum.

I'll keep testing and see what else could be in Oldnapalm's ACPI tables to help. I'll also go back over Cartri's posts and see what can be tied in.

[rayap]

Brilliant ideas and great work guys.

@tseug. Really appreciate your efforts, esp for the DumpCMOS kext. It has given us an eye on one whole bank. Wishing we can next open the other eye on the other bank.

 

It seems jumping over the rtcWrites in updateChecksum appears to work too! Need more testing. Expecting blackosx to cut his perl script by another half.

 

Poor Li Na, grass not same like clay

[karaakeha1]

EDIT:

That patched kext you've posted is working just fine here. Well done with your work rayap

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.

 

works great

[artsin]

Das mit den Patchen der AppleRTC.kext geht perfekt aber wenn ich den Ruhzustand ausgeführt habe kann ich den Ruhezustand nur mit ein klick auf einer der Maus Tasten beenden. Wenn ich auf den An/Aus Schalter des PC drücke geht der PC nach ein Paar Sekunden wieder aus aber der Ruhzustand ist aber noch aktiv. Ist bei euch auch das gleiche Problem?

 

Translate Google

 

This goes perfectly with the patching of AppleRTC.kext but when I ran the sleep I can wake it with only one click on a mouse button. When I press the on/off switch on the PC, the PC goes to a couple of seconds but the sleep is still up and running. Is also the same problem with you?

 

 

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

[blackosx]

Is also the same problem with you?

I don't experience any issues with sleep or wake from sleep. Was you system functioning perfectly before applying the AppleRTC patch?

 

Also, you've been using the older patch as there's a newer patch here.

 

@rayap - can i suggest you update your OP to reflect the current status of this topic and maybe even the topic title?

[bmas]

I don't experience any issues with sleep or wake from sleep. Was you system functioning perfectly before applying the AppleRTC patch?

 

Also, you've been using the older patch as there's a newer patch here.

 

@rayap - can i suggest you update your OP to reflect the current status of this topic and maybe even the topic title?

The pach is working. My hacky sleep and wake up, but I`m getting poor graphics after wake (HD4670).

Before sleep I get in Cinebench 11.5 21fps, after wake the FPS get down to 8..

What should be the problem..?

[allenwkk]

Yeah, but it's still better than we were at.

 

 

np. I enjoy it

Thanks for the research.

 

And for anyone wanting to try the latest patch, I've put it in to another terminal script. This is for both 32bit and 64bit.

sudo perl -pi -e 's|\xBC\x00\x74\x10|\xBC\x00\xEB\x10|; s|\x45\xB8\x74\x08|\x45\xB8\xEB\x08|; s|\xD0\x00\x74\x13|\xD0\x00\xEB\x13|; s|\x45\xCC\x74\x0B|\x45\xCC\xEB\x0B|;' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

Note: I have patched both jumps for each architecture but tseug did say that changing either jump would suffice - I just haven't tested that. So if that's the case then this patch can be even smaller.

PS. remember to backup your original AppleRTC.kext first.

 

Bed time now.

 

work great in my hackintosh.... P6E ASUS... no more cmos reset error...

[blackosx]

edit:

attached AML files from SL-10.6.8 using rtc lenght 4 in DSDT and using ElliotLegacyRTC.kext

Lion DP5 rtc lenght 4 patched rtc- ioreg shows 132 byte FACP, aml IS 244 bytes.

Lion DP4 rtc lenght 4 Not patched ( i think) ioreg SHOWS 244 byte FACP, same as AML

Hi STLVNUB

 

All three of your posted FACP.aml files have 244 bytes here. The only differences I can see between each of them are the Checksum and DSDT address.

 

Thanks for acpiexec, I'll have a look at the later.

[karaakeha1]

Das mit den Patchen der AppleRTC.kext geht perfekt aber wenn ich den Ruhzustand ausgeführt habe kann ich den Ruhezustand nur mit ein klick auf einer der Maus Tasten beenden. Wenn ich auf den An/Aus Schalter des PC drücke geht der PC nach ein Paar Sekunden wieder aus aber der Ruhzustand ist aber noch aktiv. Ist bei euch auch das gleiche Problem?

 

Translate Google

 

This goes perfectly with the patching of AppleRTC.kext but when I ran the sleep I can wake it with only one click on a mouse button. When I press the on/off switch on the PC, the PC goes to a couple of seconds but the sleep is still up and running. Is also the same problem with you?

 

 

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

 

You are Right with power switch it goes to sleep but to wake up need mouse or keyboard.

NO wakeUP with POWER Button .

And there is no such issue with Snow Leopard

So looks like both old and new patching for Lion are not perfect

[tseug]

You are Right with power switch it goes to sleep but to wake up need mouse or keyboard.

NO wakeUP with POWER Button .

And there is no such issue with Snow Leopard

So looks like both old and new patching for Lion are not perfect

 

It's not a sleep patch. It is a CMOS reset patch.

[blackosx]

@artsin & karaakeha1

 

First of all, apologies to artsin for my mis-understanding of his original post. It was only when karaakeha1 followed up with it that I realised what artsin meant.

 

I've since tested on my system the waking from sleep with the power button issue you describe and have found that I too can't wake 10.7 (10.6 works fine) from sleep with the power button, but that's with and without using the patched AppleRTC.kext. So this patch is not the culprit.

 

However, I remember the wake by power button issue being a previous DSDT fix so I guess that's the place to look for that.

 

@rayap - Well done with your updated OP and topic title.

 

Yeah but in IOReg in LionServerDP5 it shows it as being 132 bytes.

Must be a server edition only thing as the updated DP4 (11A494a) I'm running shows the FACP table fine here.

[Bansaku]

I've since tested on my system the waking from sleep with the power button issue you describe and have found that I too can't wake 10.7 (10.6 works fine) from sleep with the power button, but that's with and without using the patched AppleRTC.kext. So this patch is not the culprit.

 

However, I remember the wake by power button issue being a previous DSDT fix so I guess that's the place to look for that.

 

No problems sleeping or waking using the power button, with or without AppleRTC patch. Shouldn't the DSDT edits for PWR button sleep(/wake) be universal, at the very least for Gigabyte boards?

[og-phantom]

I'm experiencing some strange behavior. With my old Asus P5K Deluxe board, the RTC patch and changing the RTC length to 4 worked. With this EP45-UD3R, the RTC patch works (no change in behavior as far as booting goes), but, as soon as I change the RTC length to 4 in the DSDT, I get a CMOS reset every reboot. I even checked with a vanilla RTC kext, if the length of the RTC is 4, I get the CMOS reset every reboot. Change it back to 2, no problems (don't know about sleep). Any ideas?

[KariNeko]

And for anyone wanting to try the latest patch, I've put it in to another terminal script. This is for both 32bit and 64bit.

sudo perl -pi -e 's|\xBC\x00\x74\x10|\xBC\x00\xEB\x10|; 
s|\x45\xB8\x74\x08|\x45\xB8\xEB\x08|; 
s|\xD0\x00\x74\x13|\xD0\x00\xEB\x13|; 
s|\x45\xCC\x74\x0B|\x45\xCC\xEB\x0B|;' 
/System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

Note: I have patched both jumps for each architecture but tseug did say that changing either jump would suffice - I just haven't tested that. So if that's the case then this patch can be even smaller.

PS. remember to backup your original AppleRTC.kext first.

 

Bed time now.

 

Hi blackosx, so the patch above is preferred to this one below?

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"

 

With that one I could wake correctly my Asus P6T Deluxe V2 that was working correctly on Snow Leopard with a DSDT.aml file and wasn't anymore in Lion. Should I re patch the AppleRTC kext with the first quoted code?