Jump to content

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


  • Please log in to reply
485 replies to this topic

#201
STLVNUB

STLVNUB

    InsanelyMac Legend

  • Coders
  • 1,097 posts
  • Gender:Male

Here is the code:


Any chance of xcode project for this.
thanks

#202
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,053 posts
  • Gender:Male
  • Location:UK
I have DP4 (11A480b) on my iMac 11,3. :(
As to be expected, the DumpCMOS.kext shows identical results before & after a sleep/wake cycle.

Looking at RTC in ioreg doesn't tell anything different to what we already know.
Attached File  ioreg_RTC.jpg   63.93KB   66 downloads
Attached File  ioreg_AppleRTC.jpg   70.04KB   55 downloads

Here's the ACPI tables.
Attached File  iMac11_3_ACPI.zip   17.01KB   15 downloads
I won't post ioreg dump without removing serial numbers etc. first, but I will supply info from it if requested.

#203
tseug

tseug

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 407 posts
  • Gender:Male

Any chance of xcode project for this.
thanks


It's probably safer if you follow this: http://developer.app...002365-BABJHCJA

#204
Filipilon™ Katagraph®

Filipilon™ Katagraph®

    InsanelyMac Protégé

  • Members
  • PipPip
  • 52 posts

At least...

Only try the RTCS and BRTC clearance if the first mod (3 options of Device RTC itself + RMSC IO-72 clearance) do not work for you. Please feedback the different trials.
Cleaning the Waks is your choice after that. (i usually clean any "if"s and let my notify 0x2 resting in peace...)

If you think this all is too complicated, just try option 1 and nothing else....

Thanx, Cartri. I'll try ASAP. And then feedback.

EDIT:
{censored}((( Tried all mods –> but no go :(.
Stay with patched AppleRTC.kext – it just works, no CMOS errors.

#205
yonika

yonika

    InsanelyMac Protégé

  • Members
  • PipPip
  • 63 posts

Before CMOS resets after wake (then, after restart), that is exactly how my system behaved. The way I fixed it was to re-sleep via per button and wake again, that seemed to solve the problem. However, when DP4 came about, I started to get the CMOS reset after wake.
Question is DO you have any CMOS reset in Lion, at all? I went from 20% of the time getting the 'black' screen upon wake, to getting 100% CMOS reset AND reset after wake, then it went to 80% CMOS reset after wake AFTER restart. :hysterical:


Of course I have the CMOS reset issue ;)

But one of my comforts about this issue was the fact that I can use the AppleRTC.kext from 10.6.7 to avoid this issue.

With my system coming back from sleep this awkward way, I cannot really use it, even if I don't have the CMOS reset anymore because of the workaround.

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

.
.
.

EDIT2:
To double-check the above test, I ran the test again but this time with using the bin-patched AppleRTC.kext. The result for 0x2E reads 06 before and after waking from sleep showing the patched binary is no-longer changing the value.
.
.
.



What is this patched binary and where can I get it ? is it just the 10.6.7 appleRTC or something else ?

thanks
Jonathan

#206
elpekos

elpekos

    InsanelyMac Protégé

  • Members
  • Pip
  • 10 posts
post #114 (page 6 of this topic)

#207
Bansaku

Bansaku

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 177 posts
  • Gender:Male
  • Location:Edmonton
  • Interests:Lots

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.

#208
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia

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

Attached Files



#209
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,053 posts
  • Gender:Male
  • Location:UK

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 :rolleyes:

#210
tseug

tseug

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 407 posts
  • Gender:Male
Oh, the joys of lowlevel hacking :D

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: Attached File  DumpCMOS.zip   4.08KB   32 downloads

#211
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,053 posts
  • Gender:Male
  • Location:UK
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. :D

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.

#212
tseug

tseug

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 407 posts
  • Gender:Male

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? ;)

#213
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,053 posts
  • Gender:Male
  • Location:UK

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

#214
tseug

tseug

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 407 posts
  • Gender:Male

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 :P 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 :)

#215
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,053 posts
  • Gender:Male
  • Location:UK

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

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.

#216
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,836 posts
  • Gender:Male
  • Location:Brazil
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.

Attached File  acpi.tar.gz   117.25KB   33 downloads

#217
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,053 posts
  • Gender:Male
  • Location:UK
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.

#218
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,053 posts
  • Gender:Male
  • Location:UK
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:

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.

#219
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 161 posts
  • Gender:Male
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 :(

#220
karaakeha1

karaakeha1

    Mac Pro Case

  • Donators
  • 561 posts
  • Location:

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





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy