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

#61
stellarola

stellarola

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 682 posts
  • Gender:Male
  • Location:Lextown, KY
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

#62
Vlada.

Vlada.

    InsanelyMac Protégé

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

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…

#63
blackosx

blackosx

    InsanelyMacaholic

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

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.

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

Yes.

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

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

#64
stellarola

stellarola

    InsanelyMac Legend

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

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

#65
mathq

mathq

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 208 posts
  • Gender:Male
  • Location:Quebec
I have the same issue if I don't replace AppleRTC! Sleep works fine, but upon restart, CMOS resets :P

#66
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia
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...

#67
mathq

mathq

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 208 posts
  • Gender:Male
  • Location:Quebec
Mine looks like the first one, but the IRQNoFlags fix doesn't work. Still getting CMOS resets when I sleep my computer ^^

#68
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia
Did you update the Lion to the latest version 11A459e?

#69
MaLd0n

MaLd0n

    ...filling veins with juice of chaos...

  • Moderators
  • 11,137 posts
  • Gender:Male
  • Location:Rio de Janeiro
I had already tested
not work for me
:)

#70
blackosx

blackosx

    InsanelyMacaholic

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

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.

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.

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

#71
Time2Retire

Time2Retire

    Retired

  • Retired Developers
  • 1,012 posts
  • Gender:Female
  • Location:anonymouse.eu
Are people here still seeing this: "Only one ram bank..." message in kernel.log?

Try this:
[codebox] Device (RTC)
{
Name (_HID, EisaId ("PNP0B00"))
Name (_CRS, ResourceTemplate ()
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x01, // Alignment
0x08, // Length
)
IRQNoFlags ()
{8}
})
}[/codebox]
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.

#72
blackosx

blackosx

    InsanelyMacaholic

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

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?

#73
Vlada.

Vlada.

    InsanelyMac Protégé

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

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

#74
blackosx

blackosx

    InsanelyMacaholic

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

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.

#75
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 161 posts
  • Gender:Male

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!

#76
stefano.85

stefano.85

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 229 posts
  • Gender:Male
  • Location:Italy

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



#77
plprado

plprado

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 106 posts
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

#78
stellarola

stellarola

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 682 posts
  • Gender:Male
  • Location:Lextown, KY
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. :thumbsup_anim:

-Stell

#79
blackosx

blackosx

    InsanelyMacaholic

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

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.

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

Lol... I bet so too. :)

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

#80
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia
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)





2 user(s) are reading this topic

1 members, 1 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