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

#121
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male
All seems well with DP4's (Build 11A480b) AppleRTC kext after applying blackosx perl patch. It appears there is no change in code from previous build either. ;)

#122
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,160 posts
  • Gender:Male
  • Location:UK
Thanks for the confirmation rayap as I haven't tried applying the previous patch from here yet.
I see something has changed with the AppleRTC binary in 11480b as the md5 = bd73f8f6c1d5ff73392e830f280fbd31 compared with the values posted here.

EDIT:
Just grabbed some time to play with DP4 (11A480b) and I no longer have the CMOS reset using the vanilla AppleRTC.kext.
The md5 of the binary in AppleRTC.kext = bd73f8f6c1d5ff73392e830f280fbd31

So patching is no longer required. Can somebody else please confirm this to make sure I'm not seeing things?

Ignore that.. I forgot that I had to do a sleep/wake cycle before the CMOS reset occurs.. Doh!

EDIT2
Yep. Just confirming as rayap posted that this hack for the CMOS reset works for DP4.

#123
-aKy-

-aKy-

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 222 posts
  • Gender:Male
  • Location:Germany
Can confirm that this fix works, but I noticed that Auto-Sleep won't work correct. Monitor will turn off, but the PC won't shut down, the fans keep spinning. But in order to get back to the desktop, I have to "wake" up the system like I do when i put it into sleep manually.

Update: for testing Auto-sleep i put it to sleep after one minute in system prefs, reverted it after testing, but the system still trys to sleep after one minute. Maybe anyone could check if this happens on other machines too?


Will try unpatched AppleRTC and report back.

Update 2: Reverted back to original RTC, put it to never sleep and patched again to have manual sleep functionality, PC won't sleep after one minute now.

#124
kitmac

kitmac

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 209 posts
  • Gender:Male
Ok my system will shut my monitors off but my computer fans keep running....
Have to do a hard reset with the power button on the tower.
But my CMOS seems to be unaffected
Patched RTC doesnt seem to make a difference for me.

Stell i know u used to have my Mboard. Any advice?????

also my ethernet doesnt show. Using USB wireless for now.

I hear applehpet causes these types of issues. that true?

#125
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male
@-aKy-
Of course you are aware that even if you set idle-sleep to 1minute in sysprefs, the rig only hibernates after several (maybe many) minutes unlike the display.

#126
-aKy-

-aKy-

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 222 posts
  • Gender:Male
  • Location:Germany
Checked again and waited for more than 10 minutes, but system didn't hibernate. How long do you think it could take?

#127
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male

Checked again and waited for more than 10 minutes, but system didn't hibernate. How long do you think it could take?

So, with vanilla AppleRTC.kext of DP4 you have manual and idle sleeps and wakes going good, but only cmos resets on restart/startup.
With the patched AppleRTC.kext no idle sleep only but manual sleep and wakes OK? No cmos resets!

Hmmm, will have to wait and see :)

#128
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,160 posts
  • Gender:Male
  • Location:UK
Both auto sleep and manual sleep work for me as expected, with or without patching AppleRTC. So I can't confirm the patch being the cause of any problems.

All I can suggest for anyone experiencing any sleep issues is to perform a fresh installation of OS X 10.7 DP3 or 4, not an archive install, and see how your system performs before doing this patch. Then you can rule out that this hack is the cause.

#129
stellarola

stellarola

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 682 posts
  • Gender:Male
  • Location:Lextown, KY

Both auto sleep and manual sleep work for me as expected, with or without patching AppleRTC. So I can't confirm the patch being the cause of any problems.

All I can suggest for anyone experiencing any sleep issues is to perform a fresh installation of OS X 10.7 DP3 or 4, not an archive install, and see how your system performs before doing this patch. Then you can rule out that this hack is the cause.


I haven't tested sleep yet with DP4, but I'll give it a shot with and without the patch.

Thanks

-Stell

#130
r0ck3r4ever

r0ck3r4ever

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 119 posts
  • Gender:Male
I did a fresh install, sleep is not working, it shuts down the monitor, fans still running. The only way to get out of this is to press reset button. After reset, the CMOS is reseted. With the patch manual sleep works but autosleep does not.

#131
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 76 posts
  • Gender:Male
  • Location:Serbia
Nope... Auto-sleep not working in my case too with this patched 1.4 AppleeRTC.kext, and I was made also clen install of DP4...

#132
jhrfc

jhrfc

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 147 posts
  • Gender:Male
  • Location:london uk

Yep. Just confirming as rayap posted that this hack for the CMOS reset works for DP4.


You guys rock. This patch also works for me in DP4 fixing the CMOS reset on reboot after sleep problem.
Lion is now go to go for me.
Cheers
Jon

#133
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 164 posts
  • Gender:Male

Nope... Auto-sleep not working in my case too with this patched 1.4 AppleeRTC.kext, and I was made also clen install of DP4...


With vanilla AppleRTC.kext, does auto-sleep work?

#134
JUN Ho

JUN Ho

    InsanelyMac Protégé

  • Members
  • Pip
  • 42 posts
Auto-Sleep works fine with patched appleRTC.kext v.1.4, and works also without patch. I can see the timer window that shows auto-sleep will be start at 10 minutes after, when I setup auto sleep schedule.Attached File  Auto_Sleep.png   24.17KB   45 downloads

#135
Vlada.

Vlada.

    InsanelyMac Protégé

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

Auto-Sleep works fine with patched appleRTC.kext v.1.4, and works also without patch. I can see the timer window that shows auto-sleep will be start at 10 minutes after, when I setup auto sleep schedule.


Heh, well that's not the same thing... That way it works to me too, but default 10min counter setup didn't work in my case!

I will give it another shot just in case to be sure in this, because... oh, I don't know... perhaps it'll start to work properly after this schedule sleep! Who knows?!



[EDIT]

Err… Actually it seems that you are correct. It works, but at least in my case in a bit awkward way….

First I was set sleep trigger on one minute, and it didn’t work. Schedule sleep works again, but that gives me an idea! So then I was putted sleep trigger on default (10 minutes), and what happens? After 10 minutes, system shut down my monitor but my computer fans keep running, and computer stays in that position around 60 seconds or more… after that it goes to sleep completely!!!

So, it seems that it works, but... with some sort of delay or something, heh ;)

#136
Crna Brada

Crna Brada

    InsanelyMac Protégé

  • Members
  • PipPip
  • 81 posts
I went through similar thing as Vlada. I used script from post 116 (http://www.insanelym...dpost&p=1689949) on DP4 server. It worked but only forced sleep.
Then yesterday I did a fresh install of Lion DP4 but client only. Again, the forced sleep worked immediately. I waited for some 20 minutes to see if it would go on auto-sleep (set it to 10 min). It didn't!
Than, this morning, after making some setup changes (times etc.), I left the computer for an hour and when I came back it was in full sleep!?

Now everything seems to be working fine while I wouldn't bet on me being able to repeat the process which led me to this stage.

#137
Bansaku

Bansaku

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 178 posts
  • Gender:Male
  • Location:Edmonton
  • Interests:Lots
I would like to add my experience to the list here. First off, I will say that auto-sleep never worked for me (damn Samsung DVD drive prevents it so I use RIP). However, manual sleep has always worked from DP1 right up until DP4. I never experienced any CMOS reset upon wake or restart; I have been using the same DSDT I have been using in SL, which is flawless. Everything worked right up until I updated Chameleon to v2 RC5 1000 (from I believe 982, and installed 1003 today). Now in SL upon wake I cannot reconnect to my ISP (1003 fixed this problem, somehow), and in Lion I get the instant restart with the CMOS reset. Lion DP4 was a fresh install, not an update. I only added FakeSMC and RealtekRTL81XX to S/L/E as I always do, and re-patched AppleHDA. I can say with 100% certainty that before updating Chameleon I had working sleep. In both SL and Lion, I had changed nothing except use ChameleonWizard to update Chameleon, which has been working great since it's creation (and made everyone's lives easier). I already posted this here. :)

Note: SP reports everything as it should, even HDMI audio. No problems with anything else.

#138
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,160 posts
  • Gender:Male
  • Location:UK
Hi Bansaku

First off, I will say that auto-sleep never worked for me (damn Samsung DVD drive prevents it so I use RIP). However, manual sleep has always worked from DP1 right up until DP4.

For me, this topic has just been about the CMOS reset as sleep functions perfectly for me.

I never experienced any CMOS reset upon wake or restart; I have been using the same DSDT I have been using in SL, which is flawless.

You could be the first person who's posted in this topic who has not had the CMOS reset with DP1-DP3. I wonder what you have in your system that's the key to that? Any ideas?

Everything worked right up until I updated Chameleon to v2 RC5 1000 (from I believe 982, and installed 1003 today). ....... and in Lion I get the instant restart with the CMOS reset. Lion DP4 was a fresh install.

So if you go back to using a version of Chameleon prior to rev982 do I read it right that your CMOS does not get reset when rebooting after a sleep/wake cycle? Interesting....

I've always had the CMOS reset with DP1-DP4 using XPC, #####, Netkas' modded PC-EFI and Chameleon so for me I've seen no difference regardless of bootloader.

#139
LatinMcG

LatinMcG

    Insanely digesting DSDT

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 2,509 posts
  • Gender:Male
  • Location:Tampa, Florida
make sure to use lnx2mac realtek.. not the realtek driver as i seen issues with sleep .

#140
cartri

cartri

    Just a Cone

  • Donators
  • 407 posts
  • Location:Brazil

I did spot the RTC values in the FACP (FADT) previously when I was reading up about the RTC clock and it's internal registers. Maybe it's time for me to re-visit it.


Sorry for appearing from nothing in middle of the debate, but, are you using the 64bit addresses for facp?
I am not using lion on hacks yet, but got interested on this. Gigabyte motherboards have only one 32bit facp, apple's macpro firmware has 2 facp ables, one 32bit and another 64bit. As it does with other table also (repeat in 32 and 64bit), something else is selecting which table to load in osx or bootcamp, but i imagine that loading only the 64bit one would be correct for most of us.
The original facp table in gigabyte motherboards has a length of 0x74 (116) bytes, while the reconstructed 64-bit version of it goes to the standard 0xF4 (244) bytes length.
If my memory doesn't fades me, chameleon only ads some bytes related to reset to the end of the 0x74 table while applying facp patch.
For instance, my original bios has this 0x74 facp:
[000h 0000  4]					Signature : "FACP"	/* Fixed ACPI Description Table */
[004h 0004  4]				 Table Length : 00000074
[008h 0008  1]					 Revision : 01
[009h 0009  1]					 Checksum : 00	 /* Incorrect checksum, should be E6 */
[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 : "GBTU"
[020h 0032  4]		Asl Compiler Revision : 01010101

[024h 0036  4]				 FACS Address : 00000000
[028h 0040  4]				 DSDT Address : 00000000
[02Ch 0044  1]						Model : 01
[02Dh 0045  1]				   PM Profile : 01 (Desktop)
[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 : 0065
[062h 0098  2]				   C3 Latency : 03E9
[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 : 00
[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) : 000004A5
	 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) : 0
			  RTC_STS valid on S4 wake (V4) : 0
			   Remote Power-on capable (V4) : 0
				Use APIC Cluster Model (V4) : 0
	Use APIC Physical Destination Mode (V4) : 0

Raw Table Data

  0000: 46 41 43 50 74 00 00 00 01 00 47 42 54 20 20 20  FACPt.....GBT   
  0010: 47 42 54 55 41 43 50 49 31 2E 30 42 47 42 54 55  GBTUACPI1.0BGBTU
  0020: 01 01 01 01 00 00 00 00 00 00 00 00 01 01 09 00  ................
  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: 65 00 E9 03 00 00 00 00 01 03 0D 00 00 10 00 00  e...............
  0070: A5 04 00 00									  ....

it lacks the reset register that chamelleon ads, but only ads 16 bytes to it (making it length 0x84), in my case it would fix the reset, dding something like:
[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]				 Access Width : 01
[078h 0120  8]					  Address : 0000000000000CF9

[080h 0128  1]		 Value to cause reset : 06
[081h 0129  3]					 Reserved : 000000

While bytes 84 and 8C are still dynamic (zeros filled at real boot), I usually patch the whole table to repeat the same 32 bit values of PM in 64bit format like apple does in it's second facp/fadt:

[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]				 Access Width : 00
[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]				 Access Width : 00
[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  //NOTE: THIS IS CORRECTED FROM 20 IN SOME SYSTEMS, We can try 10 (16 bit) and 20 (32 bit) as options. everything with the vanilla kext, of course. Technically the correct would be 20, as the address is being re-shown as 8byte (64bit) width!
[0AEh 0174  1]				   Bit Offset : 00
[0AFh 0175  1]				 Access Width : 00
[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]				 Access Width : 00
[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 : 10
[0C6h 0198  1]				   Bit Offset : 00
[0C7h 0199  1]				 Access Width : 00
[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]				 Access Width : 00
[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 : 40
[0DEh 0222  1]				   Bit Offset : 00
[0DFh 0223  1]				 Access Width : 00
[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]				 Access Width : 00
[0ECh 0236  8]					  Address : 0000000000000000

This is one of my fixes in bios' acpi, once done you have to disable chameleon restart fix, i finish with a table like this, alreadi in 0xF4 size, like macpro's ones:
0000: 46 41 43 50 F4 00 00 00 01 74 47 42 54 20 20 20  FACP.....tGBT   
  0010: 47 42 54 55 41 43 50 49 31 2E 30 42 47 42 54 55  GBTUACPI1.0BGBTU
  0020: 01 01 01 01 00 00 EE DF 00 A0 CB 00 01 03 09 00  ................
  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: 65 00 E9 03 00 00 00 00 01 03 0D 00 00 10 00 00  e...............
  0070: A5 04 00 00 01 08 00 01 F9 0C 00 00 00 00 00 00  ................
  0080: 06 00 00 00 00 00 00 00 00 00 00 00 00 A0 CB 00  ................
  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 10 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 40 00 00  . ...........@..
  00E0: 20 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00   ...............
  00F0: 00 00 00 00

I hope this helps, can anyone test? I understand the "the less code, the better" idea, but while emulating macpro in both my p45 and X58 machines from gigabyte, I always added the full table.
I wrote an article about that back in the time i used blogspot as blog, some of you may remember...

(PS: Nice to talk again, Black)





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