Jump to content

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

rayap

By rayap,
in OSx86 10.7 (Lion)

 Share
474 posts in this topic

Recommended Posts

Hugo_bee
Hugo_bee
Posted
Posted
@ssds - Yes you copy and paste the command in to Terminal, but the command needs to be preceded by sudo:

 

sudo perl -pi -e 's|\x8b\x45\xc8\x39\x45\xcc\x74\x0b|\x8b\x45\xc8\x39\x45\xcc\xeb\x0b|; s|\x8b\x45\xb4\x39\x45\xb8\x74\x08|\x8b\x45\xb4\x39\x45\xb8\xeb\x08|' /System/Library/Extensions/AppleRTC.kext/Contents/MacOS/AppleRTC

 

confirm works on ZOTAC Geforce 9300 mini itx (MCP79a chipset)

 

great people!

Link to comment
Share on other sites
nexus77777
nexus77777
Posted
Posted

copy past ...

 

SAFE SLEEP ARGUMENTS

hibernatemode takes a bitfield argument defining SafeSleep behavior. Passing 0 disables SafeSleep altogether, forcing the computer into a regular sleep.

 

0000 0001 (bit 0) enables hibernation; causes OS X to write memory state to hibernation image at sleep time. On wake (without bit 1 set) OS X will resume from the hibernation image. Bit 0 set (without bit 1 set) causes OS X to write memory state and immedi- ately hibernate at sleep time.

 

0000 0010 (bit 1), in conjunction with bit 0, causes OS X to maintain system state in memory and leave system power on until bat- tery level drops below a near empty threshold (This enables quicker wakeup from memory while battery power is available). Upon nearly emptying the battery, OS X shuts off all system power and hibernates; on wake the system will resume from hibernation image, not from memory.

 

0000 1000 (bit 3) encourages the dynamic pager to page out inactive pages prior to hibernation, for a smaller memory footprint.

 

0001 0000 (bit 4) encourages the dynamic pager to page out more aggressively prior to hibernation, for a smaller memory footprint.

 

We do not recommend modifying hibernation settings. Any changes you make are not supported. If you choose to do so anyway, we rec- ommend using one of these three settings. For your sake and mine, please don't use anything other 0, 3, or 25.

 

hibernatemode = 0 (binary 0000) by default on supported desktops. The system will not back memory up to persistent storage. The system must wake from the contents of memory; the system will lose context on power loss. This is, historically, plain old sleep.

 

hibernatemode = 3 (binary 0011) by default on supported portables. The system will store a copy of memory to persistent storage (the disk), and will power memory during sleep. The system will wake from memory, unless a power loss forces it to restore from disk image.

 

hibernatemode = 25 (binary 0001 1001) is only settable via pmset. The system will store a copy of memory to persistent storage (the disk), and will remove power to memory. The system will restore from disk image. If you want "hibernation" - slower sleeps, slower wakes, and better battery life, you should use this setting.

 

Please note that hibernatefile may only point to a file located on the root volume.

 

Try to press again a keyboard key, then monitor was back again in my case.

 

For "normal" regular sleep: Try sleep enabler or sleepenablerNG for 10.7....

 

search in kexts.com or in Lion post install forum section...

 

...

Link to comment
Share on other sites
plprado
plprado
Posted
Posted
Just to confirm guys - setting my RTC length to 8 in my dsdt doesn't produce a cmos reset in lion and solves the rtc single bank error.

 

thanks for this info bebop68. I confirm it works here also. I have a asus p5k premium

 

edit: well, too good to be true... It does solve single bank error but it breaks my sleep, so I guess I'll have to go back to the single bank error.

Link to comment
Share on other sites
nexus77777
nexus77777
Posted
Posted
That script is working om my GA-EP45-DS3L (OSX 10.7 Lion GM)

No more bios reset after sleep

But auto sleep dos´nt work ?

I´ve attached my dsdt.aml

 

Well, same for me, on Ep45DS3 and DS3R...

I was confused between hibernation and sleep....

 

Patch/deepsleep/hibernation seems to work but sleep not, with Sleepenabler or SleepenablerNG,

sleep works (but disk shutdown so quickly and making strange noise...)

Lan have trouble don't reconnect on wake half the time...

Link to comment
Share on other sites
tseug
tseug
Posted
Posted

For anyone who reports errors:

 

Could you please check whether the error you report is caused by the patch? That is, aside from CMOS reset, does sleep/wake work with an unmodified AppleRTC?

 

As mentioned numerous times the patch is only a CMOS reset patch. It is not a general sleep patch.

Link to comment
Share on other sites
TimeWalker75a
TimeWalker75a
Posted
Posted

I can confirm the patch to be working for GM build 511, no more CMOS resets for me after sleep or restart.

My sleep, however got jerky after switching to 10.7. In Snow Leopard it used to work just fine from the first release, I had done the RTC fix to 0x02 to avoid CMOS reset back then when 10.6 was first introduced. I own a P35-DS3L Gigabyte with a E2160 and GTS250 onboard which I'm mostly masking to ICH10 in my DSDT. I have never experienced any sorts of problems related to sleep, restarts or shutdown with my setup, using a broadcom bluetooth dongle that is Mac compatible running my Apple aluminum wireless keyboard and magic mouse.

 

In 10.6 I'm able to wake my machine by pressing the power button, it power straight on and no bluetooth connection is lost during boot and my console log just seems fine, no anomalies.

In 10.7 however if I try to wake my machine on after sleep using power button it starts to wake and then goes straight to sleep, I can press, say volume up in this time frame and her the 'click' meaning the keyboard has awaken. But the machine goes back to sleep immediately. If I try to wake from power button again the situation just repeats, until I hit the power button twice to prevent it going to sleep again or hit any key on my USB keyboard on mouse. Also, when waking the machine directly from USB peripherals it wakes just normal, the bluetooth connection is not lost and my bluetooth devices stay connected.

 

Here's the log if I wake it using the power button tapped twice or a power button, then a key on my keyboard:

http://cl.ly/0o1k2V0i2v3Z0G3Z2l3t

What does it mean graphics suppressed? It shows up there no matte what I use graphics enabler from Cham or old style DSDT modification.

Here's the log if I wake it directly from a USB peripheral (old style plastic Appe Keayboard with USB 1.1 hub building with a Might Mouse connected to one of the ports):

http://cl.ly/3L1U1Z2Y0k3a0a1V122V

 

I would like to restore functionality back to how it was in 10.6 without replacing the AppleRTC next completely from 10.6. Don't mind the log about DHCP and all that stuff, It does that because the plugin for my RTL8169 card was removed in DP2 and ever since I have to use a plugin from DP1. Might as well try Realtek's official 2.0.6 some time.

Link to comment
Share on other sites
tseug
tseug
Posted
Posted
I can confirm the patch to be working for GM build 511, no more CMOS resets for me after sleep or restart.

My sleep, however got jerky after switching to 10.7.

 

I and others have the same power button problem as you have but isn't it off-topic in this thread?

Link to comment
Share on other sites
tseug
tseug
Posted
Posted
Well, yes kind of, sorry for that. I'm glad that the patch for CMOS reset worked, thanks a bunch !

Could you point me out to a discussion related to that other problem, please?

 

I dont't think there is one at the moment.

Link to comment
Share on other sites
Taruga
Taruga
Posted
Posted

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

dsdt.aml.zip

  • Like 1
Link to comment
Share on other sites
rcork
rcork
Posted
Posted

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

Link to comment
Share on other sites
longtom
longtom
Posted
Posted

It seems that it works on P55 Mobos, but not on SandyBridge.

Sleep problem topic here: WakeUp the Lion from Sleep

 

Where did you find this kext?

 

Yes, where to get it?

 

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!

Link to comment
Share on other sites
Iseeutoo
Iseeutoo
Posted
Posted
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.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

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.

  • Like 1
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

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.

 

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.

Link to comment
Share on other sites
tseug
tseug
Posted
Posted
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.insanelymac.com/forum/index.php...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.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

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 :D, 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?

 

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.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...