blackosx Posted June 16, 2011 Share Posted June 16, 2011 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. Link to comment Share on other sites More sharing options...
HFW Posted June 16, 2011 Share Posted June 16, 2011 md5 of AppleRTC binary from 11A494a = d5b581e5602b92fac80f70bd1c5c0246The 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. Link to comment Share on other sites More sharing options...
rayap Posted June 16, 2011 Author Share Posted June 16, 2011 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. Link to comment Share on other sites More sharing options...
HFW Posted June 16, 2011 Share Posted June 16, 2011 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. Link to comment Share on other sites More sharing options...
Bansaku Posted June 17, 2011 Share Posted June 17, 2011 md5 of AppleRTC binary from 11A494a = d5b581e5602b92fac80f70bd1c5c0246The 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. Link to comment Share on other sites More sharing options...
blackosx Posted June 17, 2011 Share Posted June 17, 2011 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 Link to comment Share on other sites More sharing options...
Crna Brada Posted June 17, 2011 Share Posted June 17, 2011 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 Link to comment Share on other sites More sharing options...
antipop2323 Posted June 17, 2011 Share Posted June 17, 2011 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. Link to comment Share on other sites More sharing options...
Vlada. Posted June 17, 2011 Share Posted June 17, 2011 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… Link to comment Share on other sites More sharing options...
Bansaku Posted June 17, 2011 Share Posted June 17, 2011 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. I don't mean to nitpick and be an ass, but CMOS reset after sleep is a sleep issue. Considering that the only problem with the CMOS reseting is after wake, so reporting that their sleep works, with the addition of supplying all relevant information will help us narrow down why some have CMOS resets after wake, and why some don't. I think, much like myself, people are referring to no-CMOS reset when they are talking about their sleep works. Link to comment Share on other sites More sharing options...
Crna Brada Posted June 17, 2011 Share Posted June 17, 2011 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. Isn't that amazing how many people don't understand real beauty of CMOS reset! So they keep bothering us reporting about computers going to sleep, or not, without being screwed after that - which certainly is not the point at all! Foolishly enough they also believe that methodologies proven in other areas of SW development (let's not go any further) are totally meaningless in solving issues in OSx86. Like the debugging methodology where both successful and unsuccessful results in a variety of different contexts are used to find the difference and pinpoint the root cause. Of course, utterly useless in debugging OSx86 issues... but they just don't get it. Link to comment Share on other sites More sharing options...
Bansaku Posted June 17, 2011 Share Posted June 17, 2011 p.s. i didn't check md5 as I couldn't remember the command how to do it. Open terminal and type md5 (hit space) and drag the binary from AppleRTC into terminal, hit enter. Blackosx, Here is my checksum: d5b581e5602b92fac80f70bd1c5c0246 It appears it's vanilla. So....I have no more "wake with no reboot and CMOS reset" once again without patching or reverting. Is there anything else that I could provide that might be helpful? I am upping my 2 cents to a full dollar, and still think it's Chameleon, either causing the problem, or remedying it. Maybe both. It's the only thing that has been consistent for me. Recap (short form): - I used to have no CMOS reset and reboot after wake in Lion DP1-4. - I updated Chameleon. CMOS reset and reboot problem immediately started. - I applied the patch script. CMOS reset upon wake went away however it still rebooted. - Updated Chameleon** and I had full working sleep, as in upon wake, it woke, no more reboot and CMOS reset. - Updated OS X via Software Update. AppleRTC was not patched, and I had full working sleep. You can see why I suspect Chameleon is the problem, and I think I have provided enough details to back up my original assumption. ** Current Chameleon installed is V2 RC5 r1014, updated from r1003. Here is my DSDT. dsdt.aml.zip Link to comment Share on other sites More sharing options...
antipop2323 Posted June 17, 2011 Share Posted June 17, 2011 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… +1 This. Open terminal and type md5 (hit space) and drag the binary from AppleRTC into terminal, hit enter. Blackosx, Here is my checksum: d5b581e5602b92fac80f70bd1c5c0246 It appears it's vanilla. So....I have no more "wake with no reboot and CMOS reset" once again without patching or reverting. Is there anything else that I could provide that might be helpful? I am upping my 2 cents to a full dollar, and still think it's Chameleon, either causing the problem, or remedying it. Maybe both. It's the only thing that has been consistent for me. Recap (short form): - I used to have no CMOS reset and reboot after wake in Lion DP1-4. - I updated Chameleon. CMOS reset and reboot problem immediately started. - I applied the patch script. CMOS reset upon wake went away however it still rebooted. - Updated Chameleon** and I had full working sleep, as in upon wake, it woke, no more reboot and CMOS reset. - Updated OS X via Software Update. AppleRTC was not patched, and I had full working sleep. You can see why I suspect Chameleon is the problem, and I think I have provided enough details to back up my original assumption. ** Current Chameleon installed is V2 RC5 r1014, updated from r1003. If you're saying your computer was rebooting upon wake up, that's in all likelihood an entirely separate issue. However, if you are using the vanilla AppleRTC and after waking from sleep, your next reboot doesn't cause a CMOS reset, it would be great to know what motherboard you're using and upload your DSDT as well. Link to comment Share on other sites More sharing options...
Bansaku Posted June 17, 2011 Share Posted June 17, 2011 ... it would be great to know what motherboard you're using and upload your DSDT as well. DSDT added to previous post, and my mobo is in my signature . Link to comment Share on other sites More sharing options...
blackosx Posted June 17, 2011 Share Posted June 17, 2011 Here is my DSDT. Thanks for posting your DSDT Bansaku. Maybe his "Mac Friendly" bios may have something to do with it.That is the "AMAC" in the DSDT Hi STLVNUB As far as I can tell, I don't see that AMAC does anything. It will always be set to one with OSX (because of Darwin) and will end up setting the same ResourceTemplate for Device RTC as I/we currently use (apart from the IRQ setting). I'm looking to see what else could be in Bansaku's DSDT which might be relevant. There's quite a bit which could be stripped as it's unnecessary for OSX. My original Gigabyte DSDT had similar elements. Link to comment Share on other sites More sharing options...
Bansaku Posted June 17, 2011 Share Posted June 17, 2011 Update: So previous posters got me thinking. Yes, I can now wake with no reboot and CMOS reset. Great, my original problem has been fixed. However, I had just assumed the problem with restart and CMOS reset upon wake would be essentially the same as CMOS reset AFTER restarting the system AFTER wake, something I had never experienced. Until now.... I never expected that I would get a CMOS reset after restart, AFTER wake, but I realized that since updating OS X, I never actually restarted, just slept. Normally I restart into W7 at least once per day, sometimes more. However, since the update I have been too busy with other things to do much but report my findings here, let alone play a lil' Mass Effect 2. Well, like I said, I never once, not since the early days of 10.6.1 and early adoption of the P55 chipset anyway, had I encountered a CMOS reset after restart. The only difference was that CMOS reset would happen regardless of sleep. And we all know a simple DSDT edit fixed this problem. Now I experience exactly what you good folk are. 2 steps forward, 3 steps back.... Frustration level approaching high! sigh... Link to comment Share on other sites More sharing options...
tseug Posted June 17, 2011 Share Posted June 17, 2011 Now I experience exactly what you good folk are.2 steps forward, 3 steps back.... Frustration level approaching high! sigh... Well, at least the world is now sane again Yes, the problem everyone is experiencing is CMOS reset upon sleep/wake but you won't see it until you restart. Unfortunately some people are also suffering from restart on wake which confuses the issue. Link to comment Share on other sites More sharing options...
Filipilon™ Katagraph® Posted June 18, 2011 Share Posted June 18, 2011 Well, at least the world is now sane again Yes, the problem everyone is experiencing is CMOS reset upon sleep/wake but you won't see it until you restart. Unfortunately some people are also suffering from restart on wake which confuses the issue. Just installed Lion DP4 Mac OS X 10.7 (11A494a). --> All OK, but CMOS reset after sleep/wake+restart. Any solutions (except AppleRTC.kext for Lion, SL works well)? Link to comment Share on other sites More sharing options...
vlzhukov Posted June 18, 2011 Share Posted June 18, 2011 I install AppleRTC.kext of 10.6.7 and no problem Link to comment Share on other sites More sharing options...
Bansaku Posted June 18, 2011 Share Posted June 18, 2011 Update: I am going crazy! I never expected that I would get a CMOS reset after restart, AFTER wake, but I realized that since updating OS X, I never actually restarted, just slept. This is not true. It occurred to me that after updating, and noticing in verbose that AppleHDA needed re-patching (that and the greyed out sound icon), I would more than likely need to re-patch AppleRTC at the same time, I had in fact slept the system and had a successful wake with no restart and CMOS reset (hence why I asked if the kext was over-ridden or not). So I only patched AppleHDA and restarted with no CMOS reset. (and no sound assertion warnings). The system had been put to sleep about 8 times since then until my last post. Sorry for being confusing, it's been a long week. Note: Upon the restart (and CMOS reset) I got sound assertion warnings again, though sound is ok. Odd. I as well have yet to re-patch AppleRTC. Read below... Update 2: After waking from sleep last night (the first thing I did on my system since my last post) I needed to reboot into SL to retrieve an e-mail. Expecting the CMOS reset, it booted fine! NO CMOS reset!! " What what what!!!! " I also noticed that the shutdown log was a little bit shorter, and faster. (question: how do I or where do I retrieve the shutdown log, if it's even possible?) So, I restarted into Lion this afternoon, slept and woke and restarted. CMOS reset. (sound assertion warnings popped back up, BUT repairing permissions via Disk Utility remedied this). Grrrrrrrr!!!! Groan!!! Link to comment Share on other sites More sharing options...
blackosx Posted June 18, 2011 Share Posted June 18, 2011 So you've had the case of "having" and "not having" the CMOS checksum error after a restart following a sleep/wake cycle. Are you saying you think it's something to do with patching AppleHDA? Do you think this can be made a repeatable example which I and others can try? I ask as I can't see the correlation, but at the moment I have no better suggestion to the cause, other than it's something within AppleRTC binary itself (as proven by either using the Snow Leopard version or patching the Lion 1.4 version). We've yet to determine what, if anything, is the underlying factor which the v1.4 of AppleRTC is looking for, or needs, to stop this checksum error. As another line of investigation, I've been looking at a way to load a patched FACP (FADT) table for testing different values in the hope to find another solution for the CMOS reset. To help, I've taken Valv's branch rev709 (here and here) and merged it with the Chameleon trunk 758 to allow it to boot Lion. As a result, I can now manually create a patched FADT.aml and add it in to my /Extra folder alongside my DSDT.aml for loading by the booter. However, so far I've had no success in solving the CMOS checksum error but incase anybody else fancied running some tests, I'm posting the boot file to test with. boot.zip That's enough for me today. Bed time now.. Link to comment Share on other sites More sharing options...
Bansaku Posted June 19, 2011 Share Posted June 19, 2011 So you've had the case of "having" and "not having" the CMOS checksum error after a restart following a sleep/wake cycle. Are you saying you think it's something to do with patching AppleHDA? Do you think this can be made a repeatable example which I and others can try? No no, just stating that AppleHDA keeps getting errors with the CMOS reset. However, you just made me think... Link to comment Share on other sites More sharing options...
allenwkk Posted June 19, 2011 Share Posted June 19, 2011 I just want to report that after I have upgraded from DP3 to DP4, the error message in the CMOS reset during boot are different:- DP2 DP3 : the overclock not successful. restoring to default value. DP4: a new CPU is added. press F1 to configure. My motherboard is P6T SE Link to comment Share on other sites More sharing options...
bmas Posted June 19, 2011 Share Posted June 19, 2011 I install AppleRTC.kext of 10.6.7 and no problem Is this real or only solution .. I`ve got the same problem .. My system going to sleep -> wake -> and I`ve got reset BIOS/CMOS.. that see after restart.. I`m with DSDT and don`t have such a problem with SL .. PP: I just try replacing AppleRTC on Lion with that from SL.. No effect.. Reset again .. Have also lastest Chameleon 1021 .. trunk.. Link to comment Share on other sites More sharing options...
OonihiloO Posted June 20, 2011 Share Posted June 20, 2011 Same probleme here... My dsdt was done mixing d00d's and macman's guides, No problem in SL, CMOS reset after slepp in Lion DP4... I've tested Lion with an external USB HDD, Chameleon RC5 rev 1028 (and others before) give me this error... I'll post an Ioreg of my MacBook Pro 5,1 running Lion DP4 if it can help somebody... I can also dump any ACPI tables from my MacBook Pro that could make sense to help to solve this problem, just ask and tell me how to do Link to comment Share on other sites More sharing options...
Recommended Posts