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

OonihiloO · June 20, 2011

I'll post all that tonight after work...(i'm in France, it's midday now...),

I'll try to extract ACPI tables with ACPIDumper.

If you've got anothre way to do that, tell me, but i don't have any Windows installation...

tseug · June 20, 2011

Could be, but I don't have an eSATA drive to test with.

I've been thinking, is there anyway to read the contents of CMOS from our hacks when booted in to OS X? This way we can capture it before entering sleep, then after to see what's changed or see if the checksum has changed, it might help? hmm... I've been reading and found this forum topic with a post to some assembler code, and the .COM executable for reading CMOS but it's for DOS. I might try to install a Windows VM from Lion and see if it works....

EDIT:

Well I've tested this from both 10.6 where the CMOS doesn't get reset after reboot when having woken from sleep and again from 10.7 where I do get the CMOS reset after reboot when having woken from sleep.

Differences between 10.6 and 10.7 (Values are Hex)

You're probably reading the VM simulated CMOS, not the actual CMOS.

I've looked into it a bit and reading the CMOS seems relatively simple; Write offset to port 70h, read result from port 71h. In C this can be accomplished by using inb(port) and outb(offset, port) in architecture/i386/pio.h

Unfortunately there doesn't seem to be any way of doing this in user space since the stuff that would allow it (ioperm) hasn't been ported from BSD. In other words someone needs to write a kext to dump the CMOS.

Google tells me that the checksummed part of the CMOS is situated between offset 10h to 2dh and the checksum is stored in 2eh (MSB) and 2fh (LSB). The checksum is calculated by adding the 30 bytes together in a word.

Vlada. · June 20, 2011

Unfortunately there doesn't seem to be any way of doing this in user space since the stuff that would allow it (ioperm) hasn't been ported from BSD. In other words someone needs to write a kext to dump the CMOS.

Google tells me that the checksummed part of the CMOS is situated between offset 10h to 2dh and the checksum is stored in 2eh (MSB) and 2fh (LSB). The checksum is calculated by adding the 30 bytes together in a word.

Well, one more additional kext placed in E/E or even in S/L/E, sounds to me now totally ok, but the quiz question is: Who’s going to make such kext? :thumbsdown_anim:

cartri · June 20, 2011

Almost installing dp4 into a HD just to make a few tests.

Apple usually write a length of 8 in RTC, that would make port 70 busy until 77.

So, if you are really curious about this issue and are not using stuff that reads your mobo's I/O ports (like the itf kext) you can find and remove

						IO (Decode16,
						0x0074,			 // Range Minimum
						0x0074,			 // Range Maximum
						0x01,			   // Alignment
						0x0C,			   // Length
						)

from device SYSR.

Recompile, reboot, sleep, reboot and check your cmos. Report back.

Be sure to have IO linked uneeded stuff (diskette, ps2, COM1, etc) disabled at bios also.

I will decompile the kext next weekend if I am able to find a HD for trying lion.

PS: I don't remember what is in port 0x0074, can anyone check?

OonihiloO · June 20, 2011

Here are the Dumps...

I put all that i could extract...

I'll try to go to a friend a mine next week and to test Lion DP4 on his MacPro 5,1 and dump its value...

Hope this help

Dump_MacBookPro_5_1__MB470__A____Lion_DP4_build_11A494a.zip

cartri · June 20, 2011

Thanks for the dumps, but for x58 and p45 users, MacPro@Lion would be the perfect dump (ad systemmodel, of course)

About DSDT methods to solve this I did think in more 2 (remembering I am without a install to check it myself)

Some possible fixes for the problem:

ATTENTION: TOTAL THEORIZATION, Just posting because i can not try it myself and need feedback;

Adventurers may try to insert _FIX to their RTC, also, we can try changing the alignment to 1 and play with the irq something like:

				Device (RTC)
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (_FIX, Package(1) {EISAID("PNP0B00")})
				Name (_CRS, ResourceTemplate() {IO(Decode16, 0x70, 0x70, 0x1, 0x2)})
			}

PS: The _FIX will correlate RTC to FACP/FADT

RTC wake not in fixed reg space (V1) : 0

PS2: The alignment of 1 is pure madness of mine, it is a standard of IT8720F but not used in Gigabyte's bios, after more then a year of trial and error I have found many many errors in their bios, and fixed some, sometimes they are correct, sometimes they commit unbelievable faults

PS3: Setting the IRQ to 8 will enable RTC_STS bit, what is not concomitant with the fadt/facp that says:

			  RTC_STS valid on S4 wake (V4) : 0

in both MacPros and Gigabytes.

as so, I would not recommend using it, if anyone is.

Just some ideas, sorry for posting without testing them myself (and their combination), maybe only one of the remarks I am doing solves the problem, maybe none, and maybe a combination...

I will check if my XFX5770 mini-displayport (i use apple led 27") can now handle lion (could not handle dp2 nor 10.6.8 betas, almost buying a new gpu just to test lion)

EDIT: summarizing proposed trials, and adding another:

Removing Port 74 from SYSR to free space until 77/78
Adding the _FIX to device RTC
changing alignment from 0 to 1
Trying to use or remove (logically I'd say remove if anyone is using) IRQ8 to the device
Find the Operational Region 0x000FF840 and change it's code as described bellow:

Last idea is finding SystemMemory, 0x000FF840 and changing it likely:

	OperationRegion (SMOD, SystemMemory, 0x000FF840, One)
Field (SMOD, ByteAcc, NoLock, Preserve)
{
		,   7, 
	SUSF,   1
}

to something like:

   OperationRegion (INFO, SystemMemory, 0x000FF840, One)
Field (INFO, ByteAcc, NoLock, Preserve)
{
	KBDI,   1, 
	RTCW,   1, 
	PS2F,   1, 
	IRFL,   2, 
	DISE,   1, 
	SSHU,   1
}

Using INFO or SMOD should make no difference, the deal is setting the RTCW to 1, if you want to make it hybrid the code maybe:

	OperationRegion (SMOD, SystemMemory, 0x000FF840, One)
Field (SMOD, ByteAcc, NoLock, Preserve)
{
	KBDI,   1, 
	RTCW,   1, 
	PS2F,   1, 
	IRFL,   2, 
	DISE,   1, 
	SSHU,   1
	SUSF,   1
}

Setting the SUSF bit is not used in MacPro, so you can delete this line (Remembering i am thinking in ICH10). I could not find any mentions to this on X58, ICH10, ITF IT1870F or ACPI 4.0 PDFs, "SUS" remember-me "suspend", but this is speculation, you could try with and without that line

Filipilon™ Katagraph® · June 20, 2011

	OperationRegion (SMOD, SystemMemory, 0x000FF840, One)
Field (SMOD, ByteAcc, NoLock, Preserve)
{
	KBDI,   1, 
	RTCW,   1, 
	PS2F,   1, 
	IRFL,   2, 
	DISE,   1, 
	SSHU,   1
	SUSF,   1
}
Setting the SUSF bit is not used in MacPro, so you can delete this line (Remembering i am thinking in ICH10). I could not find any mentions to this on X58, ICH10, ITF IT1870F or ACPI 4.0 PDFs, "SUS" remember-me "suspend", but this is speculation, you could try with and without that line

@Cartri, there's no "0x000FF840" region in ASUS's P5Q DSDT, what should I do to try your fix?

cartri · June 20, 2011

@Cartri, there's no "0x000FF840" region in ASUS's P5Q DSDT, what should I do to try your fix?

IF: You don't know what is around that address, try the other fixes, do not use it if it could conflict with other surrounding systemmemory (it should be free from FF840 till FF848), ELSE

You can just add the INFO code together with the other root operational regions (in the dsdt beginning you will notice some with similar code but different addresses).

The other 4 options i gave looks more promising to me, can you find yours or just attach your actual dsdt so i can view it? (i am more specialized on gigabyte's code, can't tell much about asus without seeing your dsdt)

Sorry for not testing it myself... paid more then 2 thousand dollars on the Apple Led 27" Display and as far as I can say: except you are rich, don't buy it. (I still love it anyway, but every update is a new "macumba" to make it work)

also please add your facp/fadt!

yonika · June 20, 2011

Guys, I just need a quick answer to my problem (if there's one):

I know that the main part of this thread is to solve the CMSO checksum error after sleep.

However - I have a different behavior between snow leopard and Lion when going to sleep mode.

1. The PC takes 30 seconds or less before it goes into sleep.

2. I wait

3. on SL If I take it out of sleep, usually at this time, the screen would wake up immediately

4. on Lion When I wake the system out of sleep, I get a black (blank) screen,

Unless I wait 30 seconds or so after wake, and press the keybaord a few times, the system will go back to sleep and then the screen goes black again

I'd really like to know if this is only a problem of my system, or your systems too are behaving the same way.

Thanks Jonathan

Filipilon™ Katagraph® · June 20, 2011

also please add your facp/fadt!

Original ACPI tables, saved by Everest.

ORIGINAL_ASUS_P5Q_PRO.zip

cartri · June 20, 2011

Original ACPI tables, saved by Everest.

At least you have a 0xF4 facp, already in 64/32bit format.

Your century index is already 32 and you have the same problem as us, so we can remove this possibility as the cause. Nothing to change in you FACP.

About your DSDT, just find:

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

and change it to the above, maybe you will have to try different values

//OPTION1
			Device (RTC0) // rename it to RTC if you wish, that is how macs names. Should make no diff....
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (_FIX, Package(1) {EISAID("PNP0B00")})
				Name (_CRS, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x01,			   // Alignment
						0x02,			   // Length
						)
				})
			}

//OPTION2
			Device (RTC0) // rename it to RTC if you wish, that is how macs names. Should make no diff....
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (_FIX, Package(1) {EISAID("PNP0B00")})
				Name (_CRS, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x01,			   // Alignment
						0x04,			   // Length
						)
				})
			}

//OPTION3 - ONLY USE IF YOUR BIOS HAS 2MB size (16Mbit)
			Device (RTC0) // rename it to RTC if you wish, that is how macs names. Should make no diff....
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (_FIX, Package(1) {EISAID("PNP0B00")})
				Name (_CRS, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x01,			   // Alignment
						0x08,			   // Length
						)
				})
			}

as you see it is all the same, we are only trying to add alignment to 1

also find and remove from your device (RMSC)

						IO (Decode16,
						0x0072,			 // Range Minimum
						0x0072,			 // Range Maximum
						0x00,			   // Alignment
						0x0E,			   // Length
						)

the last trial is a shot in the dark: as you see 72 until 80 are busy, using RTC to write anything bigger then 2 (like in options 2 and 3) would occupy this space. The idea of removing this is that it would free the resources for the os to write bigger length like 4 and 8 without a cmos corruption.

We could also define CMOS/CMS1/CMS2 but real macs don't do it, i don't think it would worth the trial.

It is also notable that you already have a similar RTC wake, very different from gigabytes, if nothing else works alone, try removing it's references from: OperationRegion PMS0 ; Method SWAK; and Operational Region APMP. to do so override:

SWAK:

					If (LAnd (LEqual (Arg0, One), RTCS)) {}
				Else
				{
					If (LAnd (LEqual (Arg0, 0x03), BRTC)) {}
					Else
					{
						Notify (PWRB, 0x02)
					}
				}

substitute with a simple:

					Notify (PWRB, 0x02)

For APMP:

substitute the

				Field (APMP, ByteAcc, NoLock, Preserve)
			{
						Offset (0x01), 
					,   1, 
				BRTC,   1
			}

with

				Field (APMP, ByteAcc, NoLock, Preserve)
			{
						Offset (0x01), 
					,   1, 
			}

and finally for PMS0:

				OperationRegion (PMS0, SystemIO, PMBS, 0x04)
			Field (PMS0, ByteAcc, NoLock, Preserve)
			{
					,   10, 
				RTCS,   1, 
					,   4, 
				WAKS,   1, 
						Offset (0x03), 
				PWBT,   1, 
						Offset (0x04)
			}

could be replaced with:

				OperationRegion (PMS0, SystemIO, PMBS, 0x04)
			Field (PMS0, ByteAcc, NoLock, Preserve)
			{
					,   10, 
					,   5, 
				WAKS,   1, 
						Offset (0x03), 
				PWBT,   1, 
						Offset (0x04)
			}

but i don't think this is the main cause. Your structure is very different, with many bits set by dsdt and addresses dynamically calculated based on methods, a bit more complicated, yet MSFT.

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

Oh! Don't Forget to backup your actual dsdt.aml

Bansaku · June 20, 2011

Guys, I just need a quick answer to my problem (if there's one):
4. on Lion When I wake the system out of sleep, I get a black (blank) screen,

Unless I wait 30 seconds or so after wake, and press the keybaord a few times, the system will go back to sleep and then the screen goes black again

Thanks Jonathan

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

tseug · June 20, 2011

OK, so apparently I couldn't live with myself without writing a CMOS dump kext. Here are the results. The first line is before sleep and the second line is after wake:

40 88 00 00 03 80 02 c0 ff 2f 2f 40 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 fe ff ff 06 b6
40 88 00 00 03 80 02 c0 ff 2f 2f 40 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 fe ff ff 05 b6

The checksum before sleep is correct: 0x6b6

The checksum after sleep is off by 0x100: 0x5b6

The rest is identical which is something at least.

Here is the code:

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

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

for(index = 0x10; index < 0x30; 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*/
		/* 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[0x20];

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

ReadFromCMOS(cmos);

printf("CMOS Dump:\n");

for(index = 0; index < 0x20; 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;
}

...which is basically slightly modified cut'n'paste from various sources.

This is the kext: DumpCMOS.zip

It prints to /var/log/kernel.log on load, so you'll need to load it before sleep, then unload it, sleep, wakeup, and load it again. Use kextutil and kextunload for that.

Don't put this kext in /S/L/E or /E/E. It's merely a workaround to gain access to kernel space in order to dump part of the CMOS. It certainly won't alleviate the problem and it will probably kill your cat, so don't do it.

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

bmas · June 20, 2011

OK .. I decide the problem with modded AppleRTC.kext, and now the machine didn`t reset CMOS after wake/restart...

But now new problem after waking from sleep - Choppy graphics .. I`ve got HD4670.. My FPS in Cinebench 11.5 falls down to 8, before sleep - 21 .. :angel:

elpekos · June 20, 2011

After painful DSDT problems here is my CMOS dump before and after. The mono is a G31M-ES2L with Lion DP4.

Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: CMOS Dump:
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 10: 40
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 11: 88
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 12: f0
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 13: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 14: 03
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 15: 80
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 16: 02
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 17: c0
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 18: ff
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 19: 2f
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 1a: 2f
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 1b: 40
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 1c: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 1d: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 1e: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 1f: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 20: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 21: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 22: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 23: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 24: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 25: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 26: 3c
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 27: 70
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 28: 10
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 29: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 2a: 00
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 2b: 3b
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 2c: 70
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 2d: ff
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 2e: 07
Jun 21 01:43:05 Thierrys-Mac-Pro kernel[0]: 2f: 00
Jun 21 01:43:20 Thierrys-Mac-Pro kernel[0]: DumpCMOS has stopped.
Jun 21 01:43:25 Thierrys-Mac-Pro kernel[0]: 
Jun 21 01:43:31 Thierrys-Mac-Pro kernel[0]: Wake reason: USB0
Jun 21 01:43:31 Thierrys-Mac-Pro kernel[0]: VoodooHDADevice[0xffffff8036924000]::resume
Jun 21 01:43:31 Thierrys-Mac-Pro kernel[0]: Resetting controller...
Jun 21 01:43:31 Thierrys-Mac-Pro kernel[0]: Enabling input audio routing switching at node 24:
Jun 21 01:43:31 Thierrys-Mac-Pro kernel[0]: Enabling input audio routing switching at node 26:
Jun 21 01:43:31 Thierrys-Mac-Pro kernel[0]: The USB device wired keyboard (Port 1 of Hub at 0x1d000000) may have caused a wake by being disconnected
Jun 21 01:43:31 Thierrys-Mac-Pro kernel[0]: The USB device USB Mouse (Port 2 of Hub at 0x1d000000) may have caused a wake by being disconnected
Jun 21 01:43:35 Thierrys-Mac-Pro kernel[0]: Graphics suppressed 4508 ms
Jun 21 01:43:35 Thierrys-Mac-Pro kernel[0]: 
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: Wake reason: ?
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: VoodooHDADevice[0xffffff8036924000]::resume
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: Resetting controller...
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: Enabling input audio routing switching at node 24:
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: Enabling input audio routing switching at node 26:
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: An Unknown USB Device (Port 1 of Hub at 0x1d000000), may have caused a wake by being connected
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: An Unknown USB Device (Port 2 of Hub at 0x1d000000), may have caused a wake by being connected
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: An Unknown USB Device (Port 2 of Hub at 0x5d000000), may have caused a wake by being connected
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: [iOBluetoothHCIController::setConfigState] calling registerService
Jun 21 01:43:49 Thierrys-Mac-Pro kernel[0]: CSRUSBBluetoothHCIController::setupHardware super returned 0
Jun 21 01:43:53 Thierrys-Mac-Pro kernel[0]: Graphics suppressed 4507 ms
Jun 21 01:43:55 Thierrys-Mac-Pro kernel[0]: HID tickle 6085 ms
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: DumpCMOS has started.
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: CMOS Dump:
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 10: 40
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 11: 88
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 12: f0
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 13: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 14: 03
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 15: 80
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 16: 02
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 17: c0
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 18: ff
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 19: 2f
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 1a: 2f
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 1b: 40
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 1c: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 1d: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 1e: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 1f: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 20: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 21: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 22: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 23: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 24: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 25: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 26: 3c
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 27: 70
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 28: 10
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 29: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 2a: 00
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 2b: 3b
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 2c: 70
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 2d: ff
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 2e: 05
Jun 21 01:44:03 Thierrys-Mac-Pro kernel[0]: 2f: 00
Jun 21 01:44:06 Thierrys-Mac-Pro kernel[0]: DumpCMOS has stopped.

Only byte 2E changes as before. It is decremented twice (because I had to resume twice ?). I hope it will help.

Bansaku · June 21, 2011

So, if you are really curious about this issue and are not using stuff that reads your mobo's I/O ports (like the itf kext) you can find and remove
						IO (Decode16,
						0x0074,			 // Range Minimum
						0x0074,			 // Range Maximum
						0x01,			   // Alignment
						0x0C,			   // Length
						)
from device SYSR.

Recompile, reboot, sleep, reboot and check your cmos. Report back.

Be sure to have IO linked uneeded stuff (diskette, ps2, COM1, etc) disabled at bios also.

I will decompile the kext next weekend if I am able to find a HD for trying lion.

Allright, I have been doing a little experimenting, and here is what I find. Deleting the above code does nothing. However, upon examining the DSDT edits in your other posts, I have discovered something odd with my RTC DSDT edits; it seems, the values keep getting over-ridden, when I extract the DSDT!!!

This is what I compile:

Device (RTC)
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (ATT0, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x00,			   // Alignment
						0x02,			   // Length
						)
				})
				Name (ATT1, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x00,			   // Alignment
						0x04,			   // Length
						)
				})
				Method (_CRS, 0, NotSerialized)
				{
					If (LGreaterEqual (OSFX, 0x03))
					{
						If (HPTF)
						{
							Return (ATT1)
						}
						Else
						{
							Return (ATT0)
						}
					}
					Else
					{
						Return (ATT0)
					}
				}
			}

Standard for Gigabyte mobos.

Upon extraction:

Device (RTC)
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (ATT0, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x00,			   // Alignment
						0x04,			   // Length
						)
					IRQNoFlags ()
						{8}
				})
				Name (ATT1, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x00,			   // Alignment
						0x04,			   // Length
						)
				})
				Name (ATT2, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x00,			   // Alignment
						0x02,			   // Length
						)
					IRQNoFlags ()
						{8}
				})
				Name (ATT3, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x00,			   // Alignment
						0x02,			   // Length
						)
				})
				Method (_CRS, 0, NotSerialized)
				{
					If (LGreaterEqual (OSFX, 0x03))
					{
						If (HPTF)
						{
							Return (ATT1)
						}
						Else
						{
							Return (ATT0)
						}
					}
					Else
					{
						If (LEqual (AMAC, One))
						{
							Return (ATT2)
						}

						Return (ATT0)
					}
				}
			}

Default Gigabyte values!

I have re-edited and recompiled 5 times, sleep, wake, restart, only to have my DSDT "revert" RTC to it's defaults upon extracting. AND, RTC are the ONLY values in my DSDT that keep changing. :huh:

It seems that regardless of DSDT edits, for some reason something is re-injecting or ignoring the values we compile with. Perhaps we are overlooking something that "locks" in the DSDT values upon loading. Perhaps there is something in Chameleon, maybe it's in the DSDT.

Please, all you good folk out there, can you load your DSDT from the Extras folder, then extract your DSDT and compare the two, checking if your extracted values are the same as your DSDT or "default".

I am trying out your other edits and will report back if I find anything.

cartri · June 21, 2011

Allright, I have been doing a little experimenting, and here is what I find. Deleting the above code does nothing. However, upon examining the DSDT edits in your other posts, I have discovered something odd with my RTC DSDT edits; it seems, the values keep getting over-ridden, when I extract the DSDT!!!

This is what I compile:

Standard for Gigabyte mobos.

Upon restart (after sleep/wake/restart):

Default Gigabyte values!

I have re-edited and recompiled 5 times, sleep, wake, restart, only to have my DSDT "revert" RTC to it's defaults upon extracting. AND, RTC are the ONLY values in my DSDT that keep changing.

I am trying out your other edits and will report back if I find anything.

It seems sometimes you boot from bios' dsdt, sometimes not.

Thanks for testing I was feeling alone hehe.

So I did some testings here in my machine too. the best code (no real-world difference, but it runs and comprehends the whole 70˜73 SystemIO is the one I am using above (I am using Gigabyte EX58-UD5 8Mbit/1MByte rom:

				Device (RTC)
			{
				Name (_HID, EisaId ("PNP0B00"))
				Name (_FIX, Package (0x01)
				{
					EISAID("PNP0B00")
				})
				Name (_CRS, ResourceTemplate ()
				{
					IO (Decode16,
						0x0070,			 // Range Minimum
						0x0070,			 // Range Maximum
						0x01,			   // Alignment
						0x02,			   // Length
						)
					IO (Decode16,
						0x0072,			 // Range Minimum
						0x0072,			 // Range Maximum
						0x01,			   // Alignment
						0x02,			   // Length
						)
				})
				OperationRegion (CMS1, SystemCMOS, Zero, 0x40)
				Field (CMS1, ByteAcc, NoLock, Preserve)
				{
							AccessAs (ByteAcc, 0x00), 
					CM00,   8, 
							Offset (0x21), 
					CM01,   8, 
					CM02,   16, 
							Offset (0x3F), 
					CM03,   8
				}
			}

Did you try deleting the 0x74 + using the 0x4 length?

You can give a try, at least it makes no harm (but also made no difference in snow) and can help TSEUG's initiative, Would be possible to create a program that simply returns the full CMS1?

I am still trying, as the only way to not have "single ram bank" error is by using 0x04 in the length (here between us, this is the correct length of our RTC...) but it gives us a cmos reset upon restart. Maybe Apple is trying to input data relative to SMC/TPM such as shutdownreason, I am researching yet, and found some acer notebooks with a different way to create the 0x4 field by using 2 returns of length 2.

Its fun to hack a tosh again :-)

I will try to boot this one now: //EDIT: Works, but only single bank continues, don't know about Lion, but should not give much difference, as we are not using CMS1 to do anything yet

				Device (RTC) 
			{ 
				Name(_HID, EISAID("PNP0B00"))
				Name(_FIX, Package(1) { EISAID("PNP0B00") } )
				Name(_CRS, ResourceTemplate() 
				{ 
					IO(Decode16, 0x70, 0x70, 0x1, 0x2) 
					IO(Decode16, 0x72, 0x72, 0x1, 0x2)
				})
				OperationRegion(CMS1, SystemCMOS, 0, 0x100)
				Field(CMS1, ByteAcc, NoLock, Preserve) 
				{ 
					AccessAs(ByteAcc, 0), 
					CM00, 8,
					 ,256,
					CM01, 8, 
					CM02, 16,
					, 224,
					CM03, 8,
					, 184, 
					CENT, 8
				}
			}

It is based on Intel PIIX4 southbridge, when they first integrated RTC into the chip.

I know its wrong, but I will see what happens...

Others have interesting ways of catching the CMOS.

The matter is, could we create a buffer of it before sleep and then return this buffer after sleep overriding the wrong buffer? Totally possible i guess, we just need to prepare the asl code

Bansaku · June 21, 2011

Well, been testing everything I can think of, and what was suggested. I had to restart into SL and discovered something interesting; RTC DSDT edits, done by MacMan (up until v F8 of my BIOS I would edit them myself), had no RTC edits, at all! I compared a freshly extracted DSDT (non-edited) to what MacMan posted and they are identical!!! Only HPET and TMR were edited. Now I am really confused.

In SL I have no CMOS reset using the mentioned DSDT; Everything works 100%. Knowing what I know, how is this possible? I threw my SL DSDT into Lion's E/E and restarted, and nothing has changed in terms of CMOS reset.

I will report back after more testing. :huh:

Update:

Trying different combinations.

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 (and 8),			   // Length
						)
					IO (Decode16,
						0x0072,			 // Range Minimum
						0x0072,			 // Range Maximum
						0x01,			   // Alignment
						0x04 (2, 4, 8 tried),			   // Length

No Single Ram bank 128bytes warning on start-up. CMOS reset on restart regardless of sleep.

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

Restart works fine, CMOS reset when wake/restart.

blackosx · June 21, 2011

Wow... I disappear for a couple of days and this topic goes ballistic!!!..

Great contributions here guys. Well done..

I've got some reading and testing to do now. I'll report back as I go.

You're probably reading the VM simulated CMOS, not the actual CMOS.

Lol.. that's why I never got any useful results from my test then. Thanks for checking.

I've looked into it a bit and reading the CMOS seems relatively simple...
../snip/...

Google tells me that the checksummed part of the CMOS is situated between offset 10h to 2dh and the checksum is stored in 2eh (MSB) and 2fh (LSB). The checksum is calculated by adding the 30 bytes together in a word.

When I looked in to it, the process did look quite straightforward. I'd researched the registers and the checksum location but just had no idea of how to proceed on OS X.

In other words someone needs to write a kext to dump the CMOS.

I was going to suggest that user flAked might be able to create a kext for this as I'd recently seen him do so for another project but....

OK, so apparently I couldn't live with myself without writing a CMOS dump kext.

Wow.. Nice work tseug. I'm going to test it right now.

EDIT:

After testing the CMOSDump.kext I can report the exact same results as tseug reported in post #195 where the only difference being register 0x2E having the value of 06 before sleep and 05 after waking from sleep.

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.

--------------

Welcome back to the show here cartri..

I see that exploratory mind of yours has been ticking away at various ACPI edits.. I know I've previously tried all manner of combinations while seeking this 'grail' so I will look at your suggestions soon to see if I can give any feedback.

blackosx · June 21, 2011

Apple usually write a length of 8 in RTC, that would make port 70 busy until 77.
So, if you are really curious about this issue and are not using stuff that reads your mobo's I/O ports (like the itf kext) you can find and remove
						IO (Decode16,
						0x0074,			 // Range Minimum
						0x0074,			 // Range Maximum
						0x01,			   // Alignment
						0x0C,			   // Length
						)
from device SYSR.

Recompile, reboot, sleep, reboot and check your cmos. Report back.

This change didn't make any noticeable difference to the CMOS registers or reset here.

PS: I don't remember what is in port 0x0074, can anyone check?

Intel ICH10 datasheet 319973.pdf page 439 has some info for the I/O register address map with this note:

Software must preserve the value of bit 7 at I/O addresses 70h and 74h. When writing to this address, software must first read the value, and then write the same value for bit 7 during the sequential address write. Note that port 70h is not directly readable. The only way to read this register is through Alt Access mode. Although RTC Index bits 6:0 are readable from port 74h, bit 7 will always return 0. If the NMI# enable is not changed during normal operation, software can alternatively read this bit once and then retain the value for all subsequent writes to port 70h.

Oops. look at the time.. Gotta go to work. Bye.

blackosx · June 21, 2011

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.

Here's the ACPI tables.

iMac11_3_ACPI.zip

I won't post ioreg dump without removing serial numbers etc. first, but I will supply info from it if requested.

tseug · June 21, 2011

Any chance of xcode project for this.
thanks

It's probably safer if you follow this: http://developer.apple.com/library/mac/#do...002365-BABJHCJA

Filipilon™ Katagraph® · June 21, 2011

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:

SH*T((( Tried all mods –> but no go .

Stay with patched AppleRTC.kext – it just works, no CMOS errors.

yonika · June 21, 2011

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.

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

elpekos · June 21, 2011

post #114 (page 6 of this topic)

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

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites