rayap Posted June 10, 2011 Author Share Posted June 10, 2011 Checked again and waited for more than 10 minutes, but system didn't hibernate. How long do you think it could take? So, with vanilla AppleRTC.kext of DP4 you have manual and idle sleeps and wakes going good, but only cmos resets on restart/startup. With the patched AppleRTC.kext no idle sleep only but manual sleep and wakes OK? No cmos resets! Hmmm, will have to wait and see Link to comment Share on other sites More sharing options...
blackosx Posted June 10, 2011 Share Posted June 10, 2011 Both auto sleep and manual sleep work for me as expected, with or without patching AppleRTC. So I can't confirm the patch being the cause of any problems. All I can suggest for anyone experiencing any sleep issues is to perform a fresh installation of OS X 10.7 DP3 or 4, not an archive install, and see how your system performs before doing this patch. Then you can rule out that this hack is the cause. Link to comment Share on other sites More sharing options...
stellarola Posted June 10, 2011 Share Posted June 10, 2011 Both auto sleep and manual sleep work for me as expected, with or without patching AppleRTC. So I can't confirm the patch being the cause of any problems. All I can suggest for anyone experiencing any sleep issues is to perform a fresh installation of OS X 10.7 DP3 or 4, not an archive install, and see how your system performs before doing this patch. Then you can rule out that this hack is the cause. I haven't tested sleep yet with DP4, but I'll give it a shot with and without the patch. Thanks -Stell Link to comment Share on other sites More sharing options...
r0ck3r4ever Posted June 11, 2011 Share Posted June 11, 2011 I did a fresh install, sleep is not working, it shuts down the monitor, fans still running. The only way to get out of this is to press reset button. After reset, the CMOS is reseted. With the patch manual sleep works but autosleep does not. Link to comment Share on other sites More sharing options...
Vlada. Posted June 11, 2011 Share Posted June 11, 2011 Nope... Auto-sleep not working in my case too with this patched 1.4 AppleeRTC.kext, and I was made also clen install of DP4... Link to comment Share on other sites More sharing options...
jhrfc Posted June 11, 2011 Share Posted June 11, 2011 Yep. Just confirming as rayap posted that this hack for the CMOS reset works for DP4. You guys rock. This patch also works for me in DP4 fixing the CMOS reset on reboot after sleep problem. Lion is now go to go for me. Cheers Jon Link to comment Share on other sites More sharing options...
rayap Posted June 11, 2011 Author Share Posted June 11, 2011 Nope... Auto-sleep not working in my case too with this patched 1.4 AppleeRTC.kext, and I was made also clen install of DP4... With vanilla AppleRTC.kext, does auto-sleep work? Link to comment Share on other sites More sharing options...
JUN Ho Posted June 11, 2011 Share Posted June 11, 2011 Auto-Sleep works fine with patched appleRTC.kext v.1.4, and works also without patch. I can see the timer window that shows auto-sleep will be start at 10 minutes after, when I setup auto sleep schedule. Link to comment Share on other sites More sharing options...
Vlada. Posted June 11, 2011 Share Posted June 11, 2011 Auto-Sleep works fine with patched appleRTC.kext v.1.4, and works also without patch. I can see the timer window that shows auto-sleep will be start at 10 minutes after, when I setup auto sleep schedule. Heh, well that's not the same thing... That way it works to me too, but default 10min counter setup didn't work in my case! I will give it another shot just in case to be sure in this, because... oh, I don't know... perhaps it'll start to work properly after this schedule sleep! Who knows?! [EDIT] Err… Actually it seems that you are correct. It works, but at least in my case in a bit awkward way…. First I was set sleep trigger on one minute, and it didn’t work. Schedule sleep works again, but that gives me an idea! So then I was putted sleep trigger on default (10 minutes), and what happens? After 10 minutes, system shut down my monitor but my computer fans keep running, and computer stays in that position around 60 seconds or more… after that it goes to sleep completely!!! So, it seems that it works, but... with some sort of delay or something, heh Link to comment Share on other sites More sharing options...
Crna Brada Posted June 12, 2011 Share Posted June 12, 2011 I went through similar thing as Vlada. I used script from post 116 (http://www.insanelymac.com/forum/index.php?s=&showtopic=253992&view=findpost&p=1689949) on DP4 server. It worked but only forced sleep. Then yesterday I did a fresh install of Lion DP4 but client only. Again, the forced sleep worked immediately. I waited for some 20 minutes to see if it would go on auto-sleep (set it to 10 min). It didn't! Than, this morning, after making some setup changes (times etc.), I left the computer for an hour and when I came back it was in full sleep!? Now everything seems to be working fine while I wouldn't bet on me being able to repeat the process which led me to this stage. Link to comment Share on other sites More sharing options...
Bansaku Posted June 12, 2011 Share Posted June 12, 2011 I would like to add my experience to the list here. First off, I will say that auto-sleep never worked for me (damn Samsung DVD drive prevents it so I use RIP). However, manual sleep has always worked from DP1 right up until DP4. I never experienced any CMOS reset upon wake or restart; I have been using the same DSDT I have been using in SL, which is flawless. Everything worked right up until I updated Chameleon to v2 RC5 1000 (from I believe 982, and installed 1003 today). Now in SL upon wake I cannot reconnect to my ISP (1003 fixed this problem, somehow), and in Lion I get the instant restart with the CMOS reset. Lion DP4 was a fresh install, not an update. I only added FakeSMC and RealtekRTL81XX to S/L/E as I always do, and re-patched AppleHDA. I can say with 100% certainty that before updating Chameleon I had working sleep. In both SL and Lion, I had changed nothing except use ChameleonWizard to update Chameleon, which has been working great since it's creation (and made everyone's lives easier). I already posted this here. Note: SP reports everything as it should, even HDMI audio. No problems with anything else. Link to comment Share on other sites More sharing options...
blackosx Posted June 13, 2011 Share Posted June 13, 2011 Hi Bansaku First off, I will say that auto-sleep never worked for me (damn Samsung DVD drive prevents it so I use RIP). However, manual sleep has always worked from DP1 right up until DP4. For me, this topic has just been about the CMOS reset as sleep functions perfectly for me. I never experienced any CMOS reset upon wake or restart; I have been using the same DSDT I have been using in SL, which is flawless. 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? Everything worked right up until I updated Chameleon to v2 RC5 1000 (from I believe 982, and installed 1003 today). ....... and in Lion I get the instant restart with the CMOS reset. Lion DP4 was a fresh install. 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, [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url], Netkas' modded PC-EFI and Chameleon so for me I've seen no difference regardless of bootloader. Link to comment Share on other sites More sharing options...
LatinMcG Posted June 13, 2011 Share Posted June 13, 2011 make sure to use lnx2mac realtek.. not the realtek driver as i seen issues with sleep . Link to comment Share on other sites More sharing options...
cartri Posted June 13, 2011 Share Posted June 13, 2011 I did spot the RTC values in the FACP (FADT) previously when I was reading up about the RTC clock and it's internal registers. Maybe it's time for me to re-visit it. Sorry for appearing from nothing in middle of the debate, but, are you using the 64bit addresses for facp? I am not using lion on hacks yet, but got interested on this. Gigabyte motherboards have only one 32bit facp, apple's macpro firmware has 2 facp ables, one 32bit and another 64bit. As it does with other table also (repeat in 32 and 64bit), something else is selecting which table to load in osx or bootcamp, but i imagine that loading only the 64bit one would be correct for most of us. The original facp table in gigabyte motherboards has a length of 0x74 (116) bytes, while the reconstructed 64-bit version of it goes to the standard 0xF4 (244) bytes length. If my memory doesn't fades me, chameleon only ads some bytes related to reset to the end of the 0x74 table while applying facp patch. For instance, my original bios has this 0x74 facp: [000h 0000 4] Signature : "FACP" /* Fixed ACPI Description Table */ [004h 0004 4] Table Length : 00000074 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : 00 /* Incorrect checksum, should be E6 */ [00Ah 0010 6] Oem ID : "GBT " [010h 0016 8] Oem Table ID : "GBTUACPI" [018h 0024 4] Oem Revision : 42302E31 [01Ch 0028 4] Asl Compiler ID : "GBTU" [020h 0032 4] Asl Compiler Revision : 01010101 [024h 0036 4] FACS Address : 00000000 [028h 0040 4] DSDT Address : 00000000 [02Ch 0044 1] Model : 01 [02Dh 0045 1] PM Profile : 01 (Desktop) [02Eh 0046 2] SCI Interrupt : 0009 [030h 0048 4] SMI Command Port : 000000B2 [034h 0052 1] ACPI Enable Value : A1 [035h 0053 1] ACPI Disable Value : A0 [036h 0054 1] S4BIOS Command : 00 [037h 0055 1] P-State Control : 34 [038h 0056 4] PM1A Event Block Address : 00000400 [03Ch 0060 4] PM1B Event Block Address : 00000000 [040h 0064 4] PM1A Control Block Address : 00000404 [044h 0068 4] PM1B Control Block Address : 00000000 [048h 0072 4] PM2 Control Block Address : 00000450 [04Ch 0076 4] PM Timer Block Address : 00000408 [050h 0080 4] GPE0 Block Address : 00000420 [054h 0084 4] GPE1 Block Address : 00000000 [058h 0088 1] PM1 Event Block Length : 04 [059h 0089 1] PM1 Control Block Length : 02 [05Ah 0090 1] PM2 Control Block Length : 01 [05Bh 0091 1] PM Timer Block Length : 04 [05Ch 0092 1] GPE0 Block Length : 10 [05Dh 0093 1] GPE1 Block Length : 00 [05Eh 0094 1] GPE1 Base Offset : 00 [05Fh 0095 1] _CST Support : 00 [060h 0096 2] C2 Latency : 0065 [062h 0098 2] C3 Latency : 03E9 [064h 0100 2] CPU Cache Size : 0000 [066h 0102 2] Cache Flush Stride : 0000 [068h 0104 1] Duty Cycle Offset : 01 [069h 0105 1] Duty Cycle Width : 03 [06Ah 0106 1] RTC Day Alarm Index : 0D [06Bh 0107 1] RTC Month Alarm Index : 00 [06Ch 0108 1] RTC Century Index : 00 [06Dh 0109 2] Boot Flags (decoded below) : 0010 Legacy Devices Supported (V2) : 0 8042 Present on ports 60/64 (V2) : 0 VGA Not Present (V4) : 0 MSI Not Supported (V4) : 0 PCIe ASPM Not Supported (V4) : 1 [06Fh 0111 1] Reserved : 00 [070h 0112 4] Flags (decoded below) : 000004A5 WBINVD instruction is operational (V1) : 1 WBINVD flushes all caches (V1) : 0 All CPUs support C1 (V1) : 1 C2 works on MP system (V1) : 0 Control Method Power Button (V1) : 0 Control Method Sleep Button (V1) : 1 RTC wake not in fixed reg space (V1) : 0 RTC can wake system from S4 (V1) : 1 32-bit PM Timer (V1) : 0 Docking Supported (V1) : 0 Reset Register Supported (V2) : 1 Sealed Case (V3) : 0 Headless - No Video (V3) : 0 Use native instr after SLP_TYPx (V3) : 0 PCIEXP_WAK Bits Supported (V4) : 0 Use Platform Timer (V4) : 0 RTC_STS valid on S4 wake (V4) : 0 Remote Power-on capable (V4) : 0 Use APIC Cluster Model (V4) : 0 Use APIC Physical Destination Mode (V4) : 0 Raw Table Data 0000: 46 41 43 50 74 00 00 00 01 00 47 42 54 20 20 20 FACPt.....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 00 00 00 00 00 00 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 .... it lacks the reset register that chamelleon ads, but only ads 16 bytes to it (making it length 0x84), in my case it would fix the reset, dding something like: [074h 0116 12] Reset Register : <Generic Address Structure> [074h 0116 1] Space ID : 01 (SystemIO) [075h 0117 1] Bit Width : 08 [076h 0118 1] Bit Offset : 00 [077h 0119 1] Access Width : 01 [078h 0120 8] Address : 0000000000000CF9 [080h 0128 1] Value to cause reset : 06 [081h 0129 3] Reserved : 000000 While bytes 84 and 8C are still dynamic (zeros filled at real boot), I usually patch the whole table to repeat the same 32 bit values of PM in 64bit format like apple does in it's second facp/fadt: [094h 0148 12] PM1A Event Block : <Generic Address Structure> [094h 0148 1] Space ID : 01 (SystemIO) [095h 0149 1] Bit Width : 20 [096h 0150 1] Bit Offset : 00 [097h 0151 1] Access Width : 00 [098h 0152 8] Address : 0000000000000400 [0A0h 0160 12] PM1B Event Block : <Generic Address Structure> [0A0h 0160 1] Space ID : 01 (SystemIO) [0A1h 0161 1] Bit Width : 00 [0A2h 0162 1] Bit Offset : 00 [0A3h 0163 1] Access Width : 00 [0A4h 0164 8] Address : 0000000000000000 [0ACh 0172 12] PM1A Control Block : <Generic Address Structure> [0ACh 0172 1] Space ID : 01 (SystemIO) [0ADh 0173 1] Bit Width : 10 //NOTE: THIS IS CORRECTED FROM 20 IN SOME SYSTEMS, We can try 10 (16 bit) and 20 (32 bit) as options. everything with the vanilla kext, of course. Technically the correct would be 20, as the address is being re-shown as 8byte (64bit) width! [0AEh 0174 1] Bit Offset : 00 [0AFh 0175 1] Access Width : 00 [0B0h 0176 8] Address : 0000000000000404 [0B8h 0184 12] PM1B Control Block : <Generic Address Structure> [0B8h 0184 1] Space ID : 01 (SystemIO) [0B9h 0185 1] Bit Width : 00 [0BAh 0186 1] Bit Offset : 00 [0BBh 0187 1] Access Width : 00 [0BCh 0188 8] Address : 0000000000000000 [0C4h 0196 12] PM2 Control Block : <Generic Address Structure> [0C4h 0196 1] Space ID : 01 (SystemIO) [0C5h 0197 1] Bit Width : 10 [0C6h 0198 1] Bit Offset : 00 [0C7h 0199 1] Access Width : 00 [0C8h 0200 8] Address : 0000000000000450 [0D0h 0208 12] PM Timer Block : <Generic Address Structure> [0D0h 0208 1] Space ID : 01 (SystemIO) [0D1h 0209 1] Bit Width : 20 [0D2h 0210 1] Bit Offset : 00 [0D3h 0211 1] Access Width : 00 [0D4h 0212 8] Address : 0000000000000408 [0DCh 0220 12] GPE0 Block : <Generic Address Structure> [0DCh 0220 1] Space ID : 01 (SystemIO) [0DDh 0221 1] Bit Width : 40 [0DEh 0222 1] Bit Offset : 00 [0DFh 0223 1] Access Width : 00 [0E0h 0224 8] Address : 0000000000000420 [0E8h 0232 12] GPE1 Block : <Generic Address Structure> [0E8h 0232 1] Space ID : 01 (SystemIO) [0E9h 0233 1] Bit Width : 00 [0EAh 0234 1] Bit Offset : 00 [0EBh 0235 1] Access Width : 00 [0ECh 0236 8] Address : 0000000000000000 This is one of my fixes in bios' acpi, once done you have to disable chameleon restart fix, i finish with a table like this, alreadi in 0xF4 size, like macpro's ones: 0000: 46 41 43 50 F4 00 00 00 01 74 47 42 54 20 20 20 FACP.....tGBT 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 EE DF 00 A0 CB 00 01 03 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 00 00 00 00 00 00 00 00 00 A0 CB 00 ................ 0090: 00 00 00 00 01 20 00 00 00 04 00 00 00 00 00 00 ..... .......... 00A0: 01 00 00 00 00 00 00 00 00 00 00 00 01 10 00 00 ................ 00B0: 04 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................ 00C0: 00 00 00 00 01 10 00 00 50 04 00 00 00 00 00 00 ........P....... 00D0: 01 20 00 00 08 04 00 00 00 00 00 00 01 40 00 00 . ...........@.. 00E0: 20 04 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ............... 00F0: 00 00 00 00 I hope this helps, can anyone test? I understand the "the less code, the better" idea, but while emulating macpro in both my p45 and X58 machines from gigabyte, I always added the full table. I wrote an article about that back in the time i used blogspot as blog, some of you may remember... (PS: Nice to talk again, Black) Link to comment Share on other sites More sharing options...
Bansaku Posted June 13, 2011 Share Posted June 13, 2011 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, [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url], 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 [url="http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/"]#####[/url], 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. Link to comment Share on other sites More sharing options...
cartri Posted June 13, 2011 Share Posted June 13, 2011 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 Link to comment Share on other sites More sharing options...
blackosx Posted June 13, 2011 Share Posted June 13, 2011 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). Link to comment Share on other sites More sharing options...
cartri Posted June 13, 2011 Share Posted June 13, 2011 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) Link to comment Share on other sites More sharing options...
Vlada. Posted June 13, 2011 Share Posted June 13, 2011 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… Link to comment Share on other sites More sharing options...
Bansaku Posted June 13, 2011 Share Posted June 13, 2011 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.... Moral of the story folks, if it isn't broke don't fix it. Link to comment Share on other sites More sharing options...
blackosx Posted June 14, 2011 Share Posted June 14, 2011 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?? Link to comment Share on other sites More sharing options...
Bansaku Posted June 14, 2011 Share Posted June 14, 2011 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. 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. So, that's it. Steady progress only to hit a wall. Link to comment Share on other sites More sharing options...
Vlada. Posted June 14, 2011 Share Posted June 14, 2011 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 Link to comment Share on other sites More sharing options...
Bansaku Posted June 14, 2011 Share Posted June 14, 2011 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....) Link to comment Share on other sites More sharing options...
blackosx Posted June 15, 2011 Share Posted June 15, 2011 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 Link to comment Share on other sites More sharing options...
Recommended Posts