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

#141
Bansaku

Bansaku

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 177 posts
  • Gender:Male
  • Location:Edmonton
  • Interests:Lots

Hi Bansaku


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


I was simply including all info I could think of. So many (lucky) people here have auto-sleep working.

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?


TBH I never new this problem existed until Friday when all of a sudden I had CMOS resets. My DSDT has the typical Gigabyte edits, and can be found over at Tonnymac's blog database. Nothing special. The only change I made to the Lion DSDT were some HDA edits, and I cannot see how they would cause a CMOS reset.

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.


Again, TBH I have not reverted to previous builds yet. I am seeing if future releases remedy this for me before going backwards. However, using #####, XPC, and the earliest Lion only Chameleon builds, from DP1-DP4 using any of these methods to boot, yes, I never once had a CMOS reset. The worst issue I had was that the system would not restart properly, but never resulted in CMOS reset, even doing a hard reset. And I will say this, after every install/update of Lion, the first thing I always do is hit the power button and see if I have working sleep. Up until now, it never failed to wake properly.

I have been scratching my head since Friday wondering what not only makes my system CMOS reset, but what, after reading this thread, made me immune to this. Checking the Chameleon change logs over at Sourceforge, I don't see what would cause the problem. Then again, updating from 1000 to 1003 fixed SL network problems. :)

Afterthought: Some added info that might be relevant. Chameleon was only installed on my SL drive, NOT my Lion drive. However, I accidentally did a double install of Chameleon Friday; I was not careful and installed Chameleon on my Lion drive. Could this be an issue? I am honestly been thinking about wiping the drive and re-cloning Lion to it (yes, I install Lion on an external drive using my iMac and cloning it to my Hachintosh). It may be the only way. And I don't mind at all if it can lead us to more answers. :)

#142
cartri

cartri

    Just a Cone

  • Donators
  • 407 posts
  • Location:Brazil
Sorry to go back on facp, if it is somehow offtopic, but i just compared my x58 reconstructed table with apple's macpro 5 table, found some differences and they are related to RTC & Power Management. Listing diffs:

[034h 0052 1] ACPI Enable Value : MacPro5 uses A0; Gigabyte table is using A1
[035h 0053 1] ACPI Disable Value : MacPro5 uses A1; Gigabyte table is using A0
[059h 0089 1] PM1 Control Block Length : MacPro5 uses 04; Gigabyte table is using 02
[069h 0105 1] Duty Cycle Width : MacPro5 uses 00; Gigabyte table is using 03
[06Ch 0108 1] RTC Century Index : MacPro5 uses 32; Gigabyte table is using 00

(From PM1a Event Block: )
[097h 0151 1] Access Width : MacPro5 uses 03; Gigabyte table is using 00

(From PM1a Control Block: )
[0ADh 0173 1] Bit Width : MacPro5 uses 20; Gigabyte table is using 10
[0AFh 0175 1] Access Width : MacPro5 uses 2; Gigabyte table is using 00

(From PM2 Control Block: )
[0C5h 0197 1] Bit Width : MacPro5 uses 08; Gigabyte table is using 10

(From PM Timer Block: )
[0D3h 0211 1] Access Width : MacPro5 uses 03; Gigabyte table is using 00

(From GPE0 Block: )
[0DDh 0221 1] Bit Width : MacPro5 uses 80; Gigabyte table is using 40
[0DDh 0221 1] Access Width : MacPro5 uses 04; Gigabyte table is using 00

(From GPE1 Block: )
[0EBh 0235 1] Access Width : MacPro5 uses 04; Gigabyte table is using 00


All the data from gigabyte tableis from EX58-UD5 F13Q ACPI reconstructed as shown in my last post, MP5,1 data from croped hex in ACPI table present in MP5,1 firmware update

#143
blackosx

blackosx

    InsanelyMacaholic

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

Sorry for appearing from nothing in middle of the debate, but, are you using the 64bit addresses for facp?
.../snip/...
(PS: Nice to talk again, Black)

Hey Cartri

No need for the introductory apology, it's always good to hear your technical expertise on these subjects. Welcome and thanks for your input here.

To start, yes, I'm using 64 addresses here. As per an old version of bios as you may remember.... which has the length of 0xF4 / 244 bytes.

I've compared my FACP table against an iMac11,3 and here's the differences: (I've added the MacPro5 values you've posted above)
iMac 11,3	Hack	  MacPro5

[008h 0008 1] Revision					  04		  01
[034h 0052 1] ACPI Enable Value			 F0		  A1		  A0
[035h 0053 1] ACPI Disable Value			F1		  A0		  A1
[059h 0089 1] PM1 Control Block Length	  02		  02		  04
[05Eh 0094 1] GPE1 Base Offset			  10		  00		  
[069h 0105 1] Duty Cycle Width			  01		  03		  00
[06Ch 0108 1] RTC Century Index			 32		  00		  32

[097h 0151 1] Access Width				  03		  00		  03

[0ADh 0173 1] Bit Width					 10		  10		  20
[0AFh 0175 1] Access Width				  02		  00		  02

[0C5h 0197 1] Bit Width					 08		  10		  08

[0D3h 0211 1] Access Width				  03		  00		  03

[0DDh 0221 1] Bit Width					 80		  40		  80
[0DDh 0223 1] Access Width				  04		  00		  04

[0EBh 0235 1] Access Width				  04		  00		  04

One thing I have noticed is that the Revision for my board is set to 01, other than when using RevoBoot which changes it to 04. I remember reading something about the 64bit FACP table was only introduced from Revision 03? (I need to check that).

#144
cartri

cartri

    Just a Cone

  • Donators
  • 407 posts
  • Location:Brazil

Hey Cartri

No need for the introductory apology, it's always good to hear your technical expertise on these subjects. Welcome and thanks for your input here.

To start, yes, I'm using 64 addresses here. As per an old version of bios as you may remember.... which has the length of 0xF4 / 244 bytes.

I've compared my FACP table against an iMac11,3 and here's the differences: (I've added the MacPro5 values you've posted above)

iMac 11,3	Hack	  MacPro5

[008h 0008 1] Revision					  04		  01		  04
[034h 0052 1] ACPI Enable Value			 F0		  A1		  A0
[035h 0053 1] ACPI Disable Value			F1		  A0		  A1
[059h 0089 1] PM1 Control Block Length	  02		  02		  04
[05Eh 0094 1] GPE1 Base Offset			  10		  00		  
[069h 0105 1] Duty Cycle Width			  01		  03		  00
[06Ch 0108 1] RTC Century Index			 32		  00		  32

[097h 0151 1] Access Width				  03		  00		  03

[0ADh 0173 1] Bit Width					 10		  10		  20
[0AFh 0175 1] Access Width				  02		  00		  02

[0C5h 0197 1] Bit Width					 08		  10		  08

[0D3h 0211 1] Access Width				  03		  00		  03

[0DDh 0221 1] Bit Width					 80		  40		  80
[0DDh 0223 1] Access Width				  04		  00		  04

[0EBh 0235 1] Access Width				  04		  00		  04

One thing I have noticed is that the Revision for my board is set to 01, other than when using RevoBoot which changes it to 04. I remember reading something about the 64bit FACP table was only introduced from Revision 03? (I need to check that).

Its also notable that apple sometimes uses 2 and 4 as synonymous to 32 and 64 bits in its efi modules (for instance, compare the alc885 efi 32 module and efi64 modules in hex, you shall see the mark). Changing the revision is something to do, but we must be more carefull with the other values: they need equivalences in the dsdt, else hpet could have problems (PS: added mp5,1 table rev, its also 4)

#145
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia
Just to add that in my case none of these chameleons that Bansaku mentions (982 / 1003) didn’t manage to fix CMOS reset issue… But, I must admit that is sounds pretty good to me if some future version of chameleon would be able to maintain this little thing… :)

#146
Bansaku

Bansaku

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 177 posts
  • Gender:Male
  • Location:Edmonton
  • Interests:Lots
Well, I give up (for now). After installing numerous versions of previous Chameleons, the only thing I accomplished was messing up FakeSMC somehow. In SL I had to re-install version 493, and that was only made possible by re-installing FakeSMC 2.5 in Lion, as it still booted fine. In Lion, and this is the funky part, FakeSMC 493 (and all of it's plugins) loaded fine on start-up, however once I reached the desktop, I got 5-6 Finder warnings in a row that FakeSMC was not loaded properly; All sensors and GFX were still working fine.
This was the same warning I got when I booted up Friday (after installing V2 RC5 1000 the night before). I dismissed them at the time, and they never showed up again. BUT, shortly thereafter was when I noticed sleep makes for CMOS reset.
My install method for Chameleon is manually, using the i386 folder and terminal, and recently I have been using Chameleon Wizard. FakeSMC is in E/E for SL. In Lion it is in S/L/E. Neither were touched by me today before trying out different versions of Chameleon. Never in my history of using FakeSMC + Chameleon V2 has FakeSMC failed to load.
Someone should really come up with a smilie that has a finger gun to his head and mock firing, Al Bundy style.... :P
Moral of the story folks, if it isn't broke don't fix it. :D

#147
blackosx

blackosx

    InsanelyMacaholic

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

Thanks for your long detailed posts here.

How you messed up FakeSMC by trying older versions on Chameleon - only you know that one??? I use rev477 from 6th Jan 2011 and haven't tried rev493 (what were the changes for that version? I see it here and will have to try it at some point). I use rev477 for both 10.6 and 10.7 and have tried it loading from both /E/E and /S/L/E for 10.7 with success, but I generally use it now in /S/L/E with 10.7.

I'm not sure about your Finder messages regarding FakeSMC not loaded properly as if it didn't load then your system wouldn't have booted? But it's interesting how you noticed that CMOS reset only appeared after that?

Going back to your earlier post when you didn't ever see a CMOS reset before DP4, can you post the values of your FACP(FADT) table as done so above for comparison purposes?

Your question of having the CMOS reset only when you had Chameleon installed on your Lion drive, I'm not sure about but I doubt it because I have always had Chameleon installed on a separate small partition and not to a system drive.

Oh yeah, the Al Bundy style smiley would be useful as a few times myself I could have used it to show how I was feeling :)

Its also notable that apple sometimes uses 2 and 4 as synonymous to 32 and 64 bits in its efi modules (for instance, compare the alc885 efi 32 module and efi64 modules in hex, you shall see the mark). Changing the revision is something to do, but we must be more carefull with the other values: they need equivalences in the dsdt, else hpet could have problems (PS: added mp5,1 table rev, its also 4)

Thanks for the updates. But now I'm a bit lost of how to proceed next??

#148
Bansaku

Bansaku

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 177 posts
  • Gender:Male
  • Location:Edmonton
  • Interests:Lots
Heyas Blackosx, thanks for replying.

How you messed up FakeSMC by trying older versions on Chameleon - only you know that one??? I use rev477 from 6th Jan 2011 and haven't tried rev493 (what were the changes for that version? I see it here and will have to try it at some point). I use rev477 for both 10.6 and 10.7 and have tried it loading from both /E/E and /S/L/E for 10.7 with success, but I generally use it now in /S/L/E with 10.7.


Not sure what the changes are as well, but I always (try) and keep all of my kexts up to date. And rev477 worked great, along with all of it's plugins. As for messing up FakeSMC, I am at a loss as well. The only time I re-encountered the " FakeSMC was not installed properly..." was after installing V2 RC5 r801. I thought that would be a good start as it was my first Chameleon install I used with Lion until I started to use Chameleon Wizard to try and keep up to date with the new merged branches; Used XPC previous. After I installed 801, and booted into Lion DT, I did not get the warning initially. I was checking out SystemProfiler to see if everything was being reported properly. After I closed the program and was cleaning out my D/L folder is when the warning popped up. The sensors were not among the errors, just FakeSMC.kext. Tried sleep and got CMOS reset. Rebooted, reset BIOS, and attempted to boot into SL. FakeSMC failed to load, including the sensor plug-ins. Could not get to DT, even in safe mode.

Your question of having the CMOS reset only when you had Chameleon installed on your Lion drive, I'm not sure about but I doubt it because I have always had Chameleon installed on a separate small partition and not to a system drive.


I was simply including all of my actions. Before DP4 I had Chameleon installed on that partition. Updating W7 sp1 had drive ownership problems so I had to wipe the drive and start clean. I was wanting to keep the Lion/W7 drive bootloader free (for future Windoze updates) but had a slip-up and accidentally installed it via Chameleon Wizard. I love the program, but the downside is that I no longer have my previous Chameleon installers/folder on disk. r801 was my last.

Going back to your earlier post when you didn't ever see a CMOS reset before DP4, can you post the values of your FACP(FADT) table as done so above for comparison purposes?


I will soon when I boot into Lion again. I was hoping to try and get sleep working again before I did so, but if it helps I can post it as is.

At this point I am working off from pure frustration. On Wednesday I had set up Lion to be my main; installing iStat, Docker, and iLife'11. I was quite happy with DP4. The system slept fine and woke up (semi) ok on Thursday; It woke up to a blue screen. I thought it had hung but realized I still had 2nd DVI plugged into my TV. Unlike SL who will constantly switch between single DT and dual DT until I either change input on my TV to the computer, or unplug the cable (the classic...even my iMac does that). In Lion, it just sits on a blue screen, with a nice fade in. I really like that.

If this helps, here is my boot methods and results history from the different Lion DP builds.
DP1: Clean install via iMac and cloned HD. (Carbon Copy Cloner)
XPC- Restart never worked, it would hang once OS X was finished shutting down. Sleep would work 50%; sometimes I would have to re-sleep and wake via pwr button so the GFX would wake up. No CMOS reset.
DP2: Clean install via iMac and cloned HD.
XPC- Restart still doesn't work. Sleep works the same. No CMOS reset.
Chameleon r801 Not sure which I used first- Restart doesn't work. Sleep is working better. 4/5 times it would wake up. The 1/5 it would reboot. No CMOS reset.
DP3: Updated via Software Update.
Chameleon r801-974 (I believe)- Restart works!!! Sleep works!!! No CMOS reset.
DP4: Clean install via iMac and cloned HD
Chameleon r974-986 (I believe)- Restart works, sleep works! No CMOS reset.

Using DSDT and smbios.plist (iMac 11,3) from SL, patching AppleHDA, and using only FakeSMC and lnx2mac's Realtek driver, Lion works great! I was surprised from DP1 that I has essentially 100% functionality with very little effort. I could live with no restart, and sure in the beginning having to sometimes re-sleep the system to have my GFX wake was a pain. However, things just got progressively better, until Friday. With the exception of Chameleon, I had not installed or changed anything since the initial install.
Note: I had originally re-compiled my DSDT in Lion to reflect some HDEF changes I found over at Applelife.ru for compatibility with the AppleHDA I found there. Upon patching AppleHDA for myself, I realized they were dated and bloated, and reverted to my SL DSDT.

The rest I have blathered enough about already. :P

The interesting thing with my sleep though, unlike in SL where any input would wake the system, in Lion I had to use the keyboard or power button. I would try and wake by clicking or moving mouse but nothing, so I would assume I shutdown and hit the power button, only to have the DT pop up. Even plugging in my iPod did nothing. Annoying for me to retrain myself to hit space to wake.

Last night I tried my XPC boot-stick, and I could not restart, nor could I sleep without CMOS reset. AND, XPC did not see my SL drive at all. Previous it did. :P

So, that's it. Steady progress only to hit a wall.

#149
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia
Well chameleon haves restart fix integrated so with XPC restart is not working at all... I was using EvOreboot.kext for that part in combination with XPC...

[EDIT]

Bansaku could you please attach here your DSDT and smbios.plist

#150
Bansaku

Bansaku

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 177 posts
  • Gender:Male
  • Location:Edmonton
  • Interests:Lots
Ok, here is my raw table data

Raw Table Data

  0000: 46 41 43 50 84 00 00 00 02 C8 47 42 54 20 20 20  FACP......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 7E DF 00 90 09 02 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 01 08 00 01 F9 0C 00 00 00 00 00 00  ................
  0080: 06 00 00 00									  ....

I just tried out both the script provided by Blackosx, the 10.6.7 and patched AppleRTC.kext, . Yay, no more CMOS reset after sleep! Booo, it just reboots.....

Oh, BTW, I run exclusively in 64-bit mode.

Update: After 3 5 restarts upon wake (1 each from the above methods and 2 redundant due to setting and repairing permissions to see if that helped), it magically woke fine with the script! And, well, dunno if this was the cause of it working, but this happened after I updated to Chameleon r1014. Perhaps I should throw the vanilla AppleRTC and back in and try a chain of sleeps and see if it will magically work again. But for now I am satisfied, until I sleep again and get a restart. Fingers crossed... :(

(My 2 cents is I still think Chameleon is one of the problems....)

#151
blackosx

blackosx

    InsanelyMacaholic

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

I haven't had time to read your complete posts yet, but thanks for posting your FACP table. I see you have the standard Gigabyte 0x74 table with added Chameleon restart fix, taking the length to 132 bytes (0x84).

I've added your values to the table for comparison.

iMac 11,3	Blackosx  MacPro5	Bansaku

[008h 0008 1] Revision					  04		  01		  04		02
[034h 0052 1] ACPI Enable Value			 F0		  A1		  A0		A1
[035h 0053 1] ACPI Disable Value			F1		  A0		  A1		A0
[059h 0089 1] PM1 Control Block Length	  02		  02		  04		02
[05Eh 0094 1] GPE1 Base Offset			  10		  00					00
[069h 0105 1] Duty Cycle Width			  01		  03		  00		03
[06Ch 0108 1] RTC Century Index			 32		  00		  32		00

[097h 0151 1] Access Width				  03		  00		  03

[0ADh 0173 1] Bit Width					 10		  10		  20
[0AFh 0175 1] Access Width				  02		  00		  02

[0C5h 0197 1] Bit Width					 08		  10		  08

[0D3h 0211 1] Access Width				  03		  00		  03

[0DDh 0221 1] Bit Width					 80		  40		  80
[0DDh 0223 1] Access Width				  04		  00		  04

[0EBh 0235 1] Access Width				  04		  00		  04


#152
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,083 posts
  • Gender:Male
  • Location:UK
md5 of AppleRTC binary from 11A494a = d5b581e5602b92fac80f70bd1c5c0246
The CMOS reset is back after updating, but the hack from here still works to cure the problem.

#153
HFW

HFW

    InsanelyMac Protégé

  • Members
  • PipPip
  • 84 posts
  • Gender:Male
  • Location:England

md5 of AppleRTC binary from 11A494a = d5b581e5602b92fac80f70bd1c5c0246
The CMOS reset is back after updating, but the hack from here still works to cure the problem.


Didn't work for me, CMOS reset & system reset on sleep/wake. =/

Ended up rolling back the kext to the (patched) DP4 version which didn't work either...

Back to Snow Leopard for me for now. :P

#154
rayap

rayap

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 162 posts
  • Gender:Male
Updated Lion and patched AppleRTC. All seems fine.

@HFW
What is System Reset? And, does it occur ON Sleep/Wake. Or, is it the same as CMOS Resets that occur on starts. TQ.

#155
HFW

HFW

    InsanelyMac Protégé

  • Members
  • PipPip
  • 84 posts
  • Gender:Male
  • Location:England

Updated Lion and patched AppleRTC. All seems fine.

@HFW
What is System Reset? And, does it occur ON Sleep/Wake. Or, is it the same as CMOS Resets that occur on starts. TQ.


I meant my PC starts up again as if I'd shut it down upon hitting the power button, pressing a key/clicking mouse does nothing.

#156
Bansaku

Bansaku

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 177 posts
  • Gender:Male
  • Location:Edmonton
  • Interests:Lots

md5 of AppleRTC binary from 11A494a = d5b581e5602b92fac80f70bd1c5c0246
The CMOS reset is back after updating, but the hack from here still works to cure the problem.


Question: Are we talking about having to RE-patch AppleRTC, as in you had it patched and working in DP4 and when you updated to DP5 (via Software Update assuming) it there was a new AppleRTC and that you needed to patch again? Or, are we talking about a clean DP4 updated, in which the CMOS reset still happens, and the AppleRTC needed to be patched still because the u/d did nothing to remedy the problem?

I ask because upon updating, the only kext that needed to be re-patched was AppleHDA; the new version patched actually works better, as in I no longer get sound assertion errors. Yay! Anyway, I did not have to re-patch or use a legacy AppleRTC, and I have working sleep. The only thing I touched was AppleHDA. :)

#157
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,083 posts
  • Gender:Male
  • Location:UK
Good morning Bansaku

Question: Are we talking about having to RE-patch AppleRTC, as in you had it patched and working in DP4 and when you updated to DP5 (via Software Update assuming) it there was a new AppleRTC and that you needed to patch again? Or, are we talking about a clean DP4 updated, in which the CMOS reset still happens, and the AppleRTC needed to be patched still because the u/d did nothing to remedy the problem?

Yes. I had to re-patch AppleRTC binary after performing the update from 11A480b with already patched AppleRTC. I tried rebooting after a sleep/wake cycle directly after the update to 11A494a and my BIOS reset due to CMOS checksum error. Running the hack against 11A494a's AppleRTC binary fixed the problem for me.

I ask because upon updating, the only kext that needed to be re-patched was AppleHDA.
../snip/..
Anyway, I did not have to re-patch or use a legacy AppleRTC, and I have working sleep. The only thing I touched was AppleHDA. :)

So you didn't have to re-patch 11A494a's AppleRTC binary? Not for sleep, but for the CMOS reset.

Can you check you have the same md5 values as me?
md5 from original 114480b = bd73f8f6c1d5ff73392e830f280fbd31
md5 from patched 114480b = 3842cc8c4676f9e51f6070ed0b3b171c

md5 from original 11A494a = d5b581e5602b92fac80f70bd1c5c0246
md5 from patched 11A494a = 68236440263ebfe0b7027630c465e567

the new version patched actually works better, as in I no longer get sound assertion errors. Yay!

And yes. I also find the sound assertion errors have gone with the latest AppleHDA.kext

#158
Crna Brada

Crna Brada

    InsanelyMac Protégé

  • Members
  • PipPip
  • 81 posts
I did fresh install of Lion DP4 on a SW RAID and got it running (has to be booted from another, single drive, Lion installation - Chameleon is a suspect in the case of KP when booting directly from RAID).
Then I updated Lion with the latest Apple update and finally patched AppleRTC. Sleep works, both forced and auto are fully functional.

The only exception is that the system wouldn't go to sleep automatically with Parallels running.
This might be a Parallels / Windows VM configuration issue since, if sent to forced sleep with Parallels running Windows 7, both Lion and Windows 7 wake up fully functional.

Hope this might help.

Cheers

p.s. i didn't check md5 as I couldn't remember the command how to do it.

Update: MD5 after the patch: 68236440263ebfe0b7027630c465e567

#159
antipop2323

antipop2323

    InsanelyMac Protégé

  • Members
  • Pip
  • 48 posts
this thread really isn't about people's various sleep issues (i.e. whether or not their sleep is working pre or post patching applertc) --- it's about cmos reseting on the next shutdown/restart after having used sleep. it would be rad if people made their own threads about their sleep issues, and left this one for those looking to find an alternative to patching applertc.kext to fix the cmos reset. just my 2c.

#160
Vlada.

Vlada.

    InsanelyMac Protégé

  • Members
  • PipPip
  • 66 posts
  • Gender:Male
  • Location:Serbia
Agreed, however I don’t think that we will change much here until we get more transparent picture about this little issue. This considers of course observation of more people with the same or similar problem, but also those who don’t have it. It seems to me now, that we will have two possible valid solutions. First is DSDT patch, and second is CMOS reset fix via Chameleon. So, the only one which should we take more serious in consideration is actually DSDT patch, because I think that for the Chameleon fix no one here would be able to do or help much…

And again for proper DSDT patch it would be helpful if we get at least a couple of valid DSDT-s for observation from the computers that are working properly, if… heh… there are any of those… :D





1 user(s) are reading this topic

0 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