485 replies to this topic

[stellarola]

Here's a list I've compiled from this thread of boards with the cmos reset issue. I found two instances where users had dual-core cpus listed in their signature. I'm not sure if they hadn't updated their signatures or what, but here's the list anyways.

Socket 775
Gigabyte GA-EP45-DS4P, Core2Quad Q9400
Asus P5Q, Core2Quad Q9300
Gigabyte GA-EP45-DS3L, Core2Duo E7300 (*depends if the signature is updated)
Gigabyte GA-EP45-DS4P, Core2Quad Q9400
Foxconn P35A, Core2Duo E4500 (*depends if the signature is updated)
Asus P5K-E WiFI/AP, Core2Quad E9550
Gigabyte EP45-DS3, Core2Quad Q6700
Gigabyte GA-EP45-UD3LR, Core2Quad Q6600

Socket 1366
Asus P6TSE, Core i7 930
MSI X58 Big Bang X-Power, Core i7 930
Gigabyte X58A UD7, Core i7 920

Socket 1156
Gigabyte GA-P55M-UD2, CPU Unknown
Gigabyte GA-P55A-UD4, Core i7 875k
GA-P55-USB3, Core i5 720

-Stell

[Vlada.]

stellarola, on May 16 2011, 02:46 AM, said:

Here's a list I've compiled from this thread of boards with the cmos reset issue. I found two instances where users had dual-core cpus listed in their signature. I'm not sure if they hadn't updated their signatures or what, but here's the list anyways.

Socket 775
Gigabyte GA-EP45-DS4P, Core2Quad Q9400
Asus P5Q, Core2Quad Q9300
Gigabyte GA-EP45-DS3L, Core2Duo E7300 (*depends if the signature is updated)
Gigabyte GA-EP45-DS4P, Core2Quad Q9400
Foxconn P35A, Core2Duo E4500 (*depends if the signature is updated)
Asus P5K-E WiFI/AP, Core2Quad E9550
Gigabyte EP45-DS3, Core2Quad Q6700
Gigabyte GA-EP45-UD3LR, Core2Quad Q6600


-Stell

Foxconn P35A with Core2Duo E4500 is my configuration and I can confirm that my CPU is still E4500... So I'm not sure about your theory… It seems like that there is no any pattern here and that all this happens totally random, in which of course I still don’t want to believe...

Anyway, thanks for DSDT, I’ll check it ASAP…

[blackosx]

stellarola, on May 16 2011, 12:15 AM, said:

Here's a DSDT from ASUS P5G41T-M LX & E8400 Core2Duo CPU. Sleep works without AppleRTC replacement. Check it out.

Sleep works fine for me without AppleRTC replacement. It's just the CMOS reset I suffer from.

stellarola, on May 16 2011, 12:15 AM, said:

Anyone   with a dual-core processor experiencing these cmos reset issues on   wake?

Yes.

  

stellarola, on May 16 2011, 12:46 AM, said:

Gigabyte GA-EP45-DS3L, Core2Duo E7300 (*depends if the signature is updated)

My signature is up to date, so I can confirm the E7300.

[stellarola]

blackosx, on May 16 2011, 05:33 PM, said:

Sleep works fine for me without AppleRTC replacement. It's just the CMOS reset I suffer from.

  
My signature is up to date, so I can confirm the E7300.

We're talking about the same sleep issue then, right?

The system will go into what seems like S3 sleep, but upon wake it restarts your computer and resets the cmos. This is the issue you're experiencing, correct?


Thanks for the feedback blackosx!

-Stell

[mathq]

I have the same issue if I don't replace AppleRTC! Sleep works fine, but upon restart, CMOS resets

[Vlada.]

OK. I found solution, however I’m not sure will it work on all motherboards, because the code in this DSDT for ASUS P5G41T-M LX, is pretty much different than the code that I have for my motherboard P35A. So it seems to me like that there are two possible and perhaps a bit different solutions in the code, which of course depends from the type of BIOS and motherboard.

[edit]

It seems that this doesn't work...

[mathq]

Mine looks like the first one, but the IRQNoFlags fix doesn't work. Still getting CMOS resets when I sleep my computer ^^

[Vlada.]

Did you update the Lion to the latest version 11A459e?

[MaLd0n]

I had already tested
not work for me

[blackosx]

stellarola, on May 17 2011, 01:44 AM, said:

The system will go into what seems like S3 sleep, but upon wake it restarts your computer and resets the cmos. This is the issue you're experiencing, correct?

No. My system will sleep and wake fine and stays perfectly useable until I restart or shutdown. That's when I suffer the CMOS error.

Vlada., on May 17 2011, 02:38 AM, said:

So, as you can see, it seems that missing IRQ piece of code is the fix for the actual CMOS reset problem…

Has this actually fixed the CMOS reset issue for you?
Because like MaLd0n, I've already tested with IRQ's in Device (RTC) without any success.

Vlada., on May 17 2011, 02:38 AM, said:

The obvious thing here is that the code for Device (RTC) is very differnet... It content lines which doesn’t exists in my case...

Here's a sample from my original Gigabyte DSDT extracted from acpidump. Does this look familiar when compared to the one from ASUS P5G41T-M LX ?..

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
							)
					})
					Method (_CRS, 0, NotSerialized)
					{
						If (LGreaterEqual (OSFX, 0x03))
						{
							If (HPTF)
							{
								Return (ATT1)
							}
							Else
							{
								Return (ATT0)
							}
						}
						Else
						{
							Return (ATT0)
						}
					}
				}

Most of this was stripped out from the DSDT I use now because I can see that the _CRS code logic returns either ATT1 or ATT0 which are both the same. That's also why ATT1 has been stripped.

Having said all this, I will test again just to double check things but keep looking as the answer is there somewhere.

[Time2Retire]

Are people here still seeing this: "Only one ram bank..." message in kernel.log?

Try this:

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

I use 0x08 here since there are actually 8 RTC registers, as combo of a data and index register.

See also Intel's datasheet for your chipset.

[blackosx]

Hi DHP.

I'm at work now so I can't check my kernel log for that message, but I think I've previously tried the Device (RTC) section you posted purely because that's exactly what my iMac11,3 uses... though looking at it again now, the iMac version doesn't have the IRQ part so now I'm not sure what I tried.. That'll teach me not to have written down my various attempts here  

I've got the Intel datasheet 319973.pdf for ICH10 here which I will look at again for ideas, so I guess I have more reading to do.. I'll look more in to the registers.

I currently have in my DSDT for HPET and RTC:

 Device (HPET)
				{
					Name (_HID, EisaId ("PNP0103"))
					Name (_STA, 0x0F)
					Name (_CRS, ResourceTemplate ()
					{
						IRQNoFlags ()
							{0}
						IRQNoFlags ()
							{8}
						Memory32Fixed (ReadWrite,
							0xFED00000,		 // Address Base
							0x00000400,		 // Address Length
							)
					})
				}

				Device (RTC)
				{
					Name (_HID, EisaId ("PNP0B00"))
					Name (_CRS, ResourceTemplate ()
					{
						IO (Decode16, 0x0070, 0x0070, 0x00, 0x02, )
					})
				}

For interrupts, the Intel datasheet reads

Quote

5.11.2 Interrupts
The real-time clock interrupt is internally routed within the ICH10 both to the I/O APIC and the 8259. It is mapped to interrupt vector 8. This interrupt does not leave the ICH10, nor is it shared with any other interrupt. IRQ8# from the SERIRQ stream is ignored. However, the High Performance Event Timers can also be mapped to IRQ8#; in this case, the RTC interrupt is blocked.

So I interpret this that I don't need the IRQ in Device (RTC) as in your section - would I be right with that assumption?

[Vlada.]

blackosx, on May 17 2011, 08:06 AM, said:

Has this actually fixed the CMOS reset issue for you?
Because like MaLd0n, I've already tested with IRQ's in Device (RTC) without any success.

Yes. It's working in my case and I don't have any more CMOS reset. I make twice sleep/wake/restart operation from Lion and everything was been fine after that... (Lion updated to 11A459e)

Hmm... well I was suspected that this little fix will not working on all motherboards, but I didn't expected this...  
So I guess at least that it pointing in good direction...

[edit]

Well, this also doesn’t stand anymore… It was worked a couple of times and after I was saw here that IRQ piece of code was helped non of you I was decided to switch one more time AppleRTC.kext except this time I was extracted it directly from latest update, just to be sure that everything is fine… However, after that rollback I was become aware that it actually doesn’t work again to me too!!! Strange, because I did rollback on original AppleRTC.kext, and I had 3 or 4 times CMOS reset before I made those changes in DSDT. After those changes I was successfully restarted my computer 3 times…  Tomorrow I was made once more rollback just to be sure that everything is fine, but after that I was become aware that it doesn’t work again…

So this isn’t solution, but obviously big fail… Sorry for this guys…

I’m confused now what really happens… I need to make more tests to figure what’s going on… Damn...

[blackosx]

Vlada., on May 17 2011, 10:35 AM, said:

Yes. It's working in my case and I don't have any more CMOS reset. I make twice sleep/wake/restart operation from Lion and everything was been fine after that...

Thanks for the confirmation. In that case well done, you seem to have cracked it!!
For me, I need to test this when I get back to my hack. As I can't remember exactly what I've tried.

[rayap]

DutchHockeyPro, on May 17 2011, 07:45 AM, said:

I use 0x08 here since there are actually 8 RTC registers, as combo of a data and index register.

Even without sleep, length 0x04 or 0x08 causes CMOS resets for me.
And, 'kernel: RTC: Only single RAM bank (128 bytes)' msg for length 0x02 only but resets CMOS after sleep with AppleRTC v1.4

P.S. AppleRTCv1.4 causes CMOS Resets After Sleep in SnowLeopard too!

[stefano.85]

Vlada., on May 17 2011, 03:38 AM, said:

OK. I found solution, however I’m not sure will it work on all motherboards, because the code in this DSDT for ASUS P5G41T-M LX, is pretty much different than the code that I have for my motherboard P35A. So it seems to me like that there are two possible and perhaps a bit different solutions in the code, which of course depends from the type of BIOS and motherboard.

Unfortunately for me add "IRQNoFlags () {8}" in my rtc dsdt part didn't fix the problem.
I'm attaching my dsdt (working in snow) and my lion's kernel.log with applertc from snow if it helps.

Attached Files

•  dsdt_P5Q.zip   16.06K   13 downloads
•  kernel_log.rtf   8.29K   8 downloads

[plprado]

same for me here:  "IRQNoFlags () {8}" in my rtc dsdt part didn't fix the problem.

Using AppleRTC.kext from 10.6 solves this issue but I really wish someone can find out a DSDT solution...Actually I'm sure someone will, it's just a matter of time.

I'm on a Asus P5K-Premium

My current DSDT works flawlessly in 10.6.7

[stellarola]

Yea, ICH10 here. Adding IRQ 8 to RTC section doesn't seem to fix or break anything anymore than not using it. CMOS reset still persists on my board.

I'm sure the answer is right in front of us, thats the worst part.

-Stell

[blackosx]

stellarola, on May 17 2011, 09:09 PM, said:

Adding IRQ 8 to RTC section doesn't seem to fix or break anything anymore than not using it. CMOS reset still persists on my board.

Same here. No difference to the CMOS reset.
I've also tried a few more variations with changes to Device (RTC) and Device (HPET) without any joy.

stellarola, on May 17 2011, 09:09 PM, said:

I'm sure the answer is right in front of us, thats the worst part.

Lol... I bet so too.

Vlada., on May 17 2011, 10:35 AM, said:

If someone wants to check my DSDT, no problem…
You have download link down in my signature, except of course that one doesn’t content this little fix.

Can you post your DSDT here please? so I don't have to create an account at kexts.com. Thanks

[Vlada.]

Well, one more 100% working DSDT would be helpful now, but from some lga775 Gigabyte motherboard… This one from Asus is totally different in many segments from mine, but it seems that the piece of code for Device (RTC) which I found in it, is actually ok…

I also found that conformation in this topic and the code in last post is exactly the same like the one in this Ausus DSDT that Stellarola was attached here: http://www.insanelym...howtopic=191037

So maybe we should focus on the last part of that code example and try to figure what it really do?

It’s the same routine that I found that is used for Device (HPET), (RTC) and (TMR) in this ASUS P5G41T-M LX (DSDT)