stefano.85 Posted May 17, 2011 Share Posted May 17, 2011 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. dsdt_P5Q.zip kernel_log.rtf Link to comment Share on other sites More sharing options...
plprado Posted May 17, 2011 Share Posted May 17, 2011 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 Link to comment Share on other sites More sharing options...
stellarola Posted May 17, 2011 Share Posted May 17, 2011 Yea, ICH10 here. Adding IRQ 8 to RTC section doesn't seem to fix or break anything anymore than not using it. CMOS reset still persists on my board. I'm sure the answer is right in front of us, thats the worst part. -Stell Link to comment Share on other sites More sharing options...
blackosx Posted May 17, 2011 Share Posted May 17, 2011 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 Link to comment Share on other sites More sharing options...
Vlada. Posted May 17, 2011 Share Posted May 17, 2011 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.insanelymac.com/forum/index.php?showtopic=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) Link to comment Share on other sites More sharing options...
blackosx Posted May 19, 2011 Share Posted May 19, 2011 Well I'm still pi**ing in the wind here with this, though I've read more of the ACPI spec and Intel ICH10 spec sheet. Trouble is trying to understand it and how it translates to the problem here. I looked at DHP's question of 'Are people here still seeing this: "Only one ram bank..." message in kernel.log?' and rayap's response concur's here with the message only showing if a length of 0x02 is used. This makes more sense to me now as I know there are two banks (standard and extended) to my RTC. When I looked through my kernel log though, I saw an occurence where the date had changed to December 24th with the message 'RTC: lost battery power - time may be invalid'.?? This happended yesterday when I was doing more of my 'stupidly undocumented (why don't I ever write down what I've done)' trial and error changes to my DSDT so unfortunately I can't remember what I did to cause it. This might be nothing, but at least it's something that shows me that making changes does effect the RTC in a manner that I can see. Link to comment Share on other sites More sharing options...
jacoweb Posted May 19, 2011 Share Posted May 19, 2011 installed the AppleRTC kext from 10.6.7 and sleep is now working on my hack! Gigabyte x58a UD7. Thanks! But i hope for a proper fix later Link to comment Share on other sites More sharing options...
blackosx Posted May 19, 2011 Share Posted May 19, 2011 Looking at both AppleRTC binaries (v1.3.1 and v1.4) in a hex editor I can see many more strings in v1.4 referring to RTC. v1.3.1 AppleRTC Binary - v1.3.1 rootAppleRTCUserClientAppleRTCRTC: %s setting ignored Wake TypeAlarmMaintenance maintenanceRTC:%s alarm %u/%u/%u %02u:%02u:%02u, sleep %u/%u/%u %02u:%02u:%02u IOHibernateRTCVariables/optionsRTC: disableAlarm failed (StatusB = %02x) RTC: map device memory failed RTC: invalid device register map RTC: Only single RAM bank (128 bytes) RTC: no memory for RAM shadow RTC: lost battery power - time may be invalid FACPRTC: installInterruptForFixedEvent() failed RTC: registerInterrupt() failed %x WakeByCalendarDatePowerByCalendarDateWakeRelativeToSleepPowerRelativeToShutdownMaintenanceWakeCalendarDate"¬ Multiple inheritance is not supported"@/System/Library/Frameworks/Kernel.framework/PrivateHeaders/libkern/c++/OSMetaClass.h:¬ 324IOPMRegisterNVRAMTracePointHandlerIOPlatformWakeActionIORTCIOHibernateState com.apple.driver.AppleRTC1.3.1 v1.4.1 rootAppleRTCUserClientAppleRTCRTC: rtcWrite( 0x%x ) error RTC: rtcRead( 0x%x ) error RTC: Invalid %s - Date %u/%u/%u Time %u:%u:%u RTC: %s setting ignored RTC: calendar wake = %d RTC: calendar power-on = %d RTC: alarm seconds = %u RTC: power-on seconds = %u RTC: [%s] not handled RTC: [%s] Y %d, M %d, D %d, H %d, M %d, S %d (%x) Wake TypeAlarmRTC: acting on wake from Alarm RTC: updated wake type to maintenance Maintenance maintenanceRTC:%s alarm %u/%u/%u %02u:%02u:%02u, sleep %u/%u/%u %02u:%02u:%02u RTC: setGMTTimeOfDay %ld RTC: fixedEventHandler %02x RTC: enableAlarm (StatusC = %02x) RTC: systemWillShutdown was not called RTC: getGMTTimeOfDay %ld RTC: disableAlarm RTC: disableAlarm (%d retry) RTC: disableAlarm failed (StatusB = %02x) RTC: setPowerState %u RTC: rtcSafeRead( 0x%x ) error 0 1 2 3 4 5 6 7 8 9 A B C D E F ----------------------------------------------- %02x RTC: alarm has already expired, alarm %ld, now %ld RTC: alarm time Month %02x, Day %02x, Time %02x:%02x:%02x RTC: current time Month %02x, Day %02x, Time %02x:%02x:%02x RTC: setupDateTimeAlarm update retry RTC: setupDateTimeAlarm done (%d retry) rtcIOHibernateStateRTC: map device memory failed RTC: invalid device register map RTC: Only single RAM bank (128 bytes) RTC: no memory for RAM shadow RTC: lost battery power - time may be invalid FACPRTC: DayAlarm register at 0x%x RTC: MonAlarm register at 0x%x RTC: installInterruptForFixedEvent() failed RTC: registerInterrupt() failed %x WakeByCalendarDatePowerByCalendarDateWakeRelativeToSleepPowerRelativeToShutdownMaintenanceWakeCalendarDate¬ IOPMRegisterNVRAMTracePointHandlerRTC: registered tracepoint handler 0x%08x 0x%08x IOPlatformWakeActionIORTCRTC: rtcWriteBytes( %p, 0x%x, 0x%x ) error RTC: writeBytes( data %p, offset 0x%x, size 0x%x ) took %llu us RTC: setHibernateState() error IOHibernateRTCVariables/optionsRTC: Restored entire RTC RAM RTC: Restored hibernation control RTC: rtcReadBytes( %p, 0x%x, 0x%x ) error RTC: readBytes( data %p, offset 0x%x, size 0x%x ) took %llu us RTC: TracePoint(%08x, %08x, %08x) thread %p, writes %d, %ccrc %04x, hib %u, took %llu us RTC: setAlarmEnable 0x%x RTC: enabled wake alarm RTC: enabled power-on alarm com.apple.driver.AppleRTC1.4 It seems Apple are doing much more with this version of the kext now.... EDIT: This line looks interesting RTC: writeBytes( data %p, offset 0x%x, size 0x%x ) took %llu us Link to comment Share on other sites More sharing options...
rayap Posted May 19, 2011 Author Share Posted May 19, 2011 @BlackOSX Refresh: http://www.insanelymac.com/forum/index.php...t&p=1200071 Link to comment Share on other sites More sharing options...
blackosx Posted May 19, 2011 Share Posted May 19, 2011 @BlackOSX Refresh: http://www.insanelymac.com/forum/index.php...t&p=1200071 Hi rayap - Thanks for the link I see Azi posted about the 'RTC: lost battery power - time may be invalid' error when he changed the address range which is what I did the other night so that must have been the cause of me also seeing that particular error in the kernel.log. I'll look more in to that post a bit later as I have to go out now.... be back later EDIT: Oh.. and the reason I/(we) use Device (RTC) and Device (TIMR) as we do now, without ATT0/ATT1 is mainly down to MasterChief when he posted this in the Gigabyte DSDT topic. Link to comment Share on other sites More sharing options...
blackosx Posted May 19, 2011 Share Posted May 19, 2011 I thought I'd be clever (yes, I've been reading DHP's topic) and use otool to disassemble both v1.3.1 and v1.4 of the AppleRTC binaries and now I'm completely lost and drowning in a sea of mnemonics.... I think now's the time to stop and just be happy to use JUN Ho's trick. Link to comment Share on other sites More sharing options...
stefano.85 Posted May 19, 2011 Share Posted May 19, 2011 I thought I'd be clever (yes, I've been reading DHP's topic) and use otool to disassemble both v1.3.1 and v1.4 of the AppleRTC binaries and now I'm completely lost and drowning in a sea of mnemonics.... I think now's the time to stop and just be happy to use JUN Ho's trick. LOL i think you've already done so much work.... go to sleep for today and don't think so much to it... Unfortunately i'm not a coder and i can't do so much...I think the solution is out there and that some gurus are already working on this. cheers! Link to comment Share on other sites More sharing options...
blackosx Posted May 19, 2011 Share Posted May 19, 2011 Hi stefano.85. Thanks. I'm no coder either (well, at least not low-level stuff) and yes, it's time to give it a rest. Hopefully somebody else will shine the light on this problem.. Link to comment Share on other sites More sharing options...
stellarola Posted May 19, 2011 Share Posted May 19, 2011 I wish I was smarter to figure this out. Bump. Link to comment Share on other sites More sharing options...
Vlada. Posted May 19, 2011 Share Posted May 19, 2011 Yeah, me too… And blackosx, you are not alone… I was working really hard in a last 24h to crack this one… What most is troubling me is the fact that I was managed to restart my computer properly a couple of times, but now it simply refuses to work… I’m really confused what happens, because as I said, I had 3 or 4 times CMOS reset and then I was made some changes in DSDT and managed to make 3 times sleep/wake/restart operation properly. After second rollback it didn’t want to work again… I regret now one thing and that is the fact that I didn’t backup my DSDT from that stage, but I was continue to mass with him further… During my work I was really made a lot of drastic changes in it and now I’m not sure anymore how some parts was looked like in that very moment. I was even manage to built another variation of my DSDT which is also working vanilla but this one is built from original code components for Device (RTC), (HPET) and (TIMR), which I was cut and paste directly from MacPro3,1 DSL. So here is my observation for that part… This is a piece of code that I was using previously: Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (ATT3, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadWrite, 0xFED00000, // Address Base 0x00000400, // Address Length ) }) Name (ATT4, ResourceTemplate () { }) Method (_STA, 0, NotSerialized) { Return (0x0F) } Method (_CRS, 0, NotSerialized) { Return (ATT3) } } Device (TMR) { Name (_HID, EisaId ("PNP0100")) Name (ATT6, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x02, // Length ) }) Method (_CRS, 0, NotSerialized) { Return (ATT6) } } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (ATT0, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x02, // Length ) }) Name (ATT1, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x02, // Length ) }) Method (_CRS, 0, NotSerialized) { Return (ATT0) } } This is the MacPro3,1 code: Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length _Y09) }) Method (_STA, 0, NotSerialized) { If (LGreaterEqual (OSYS, 0x07D1)) { If (HPAE) { Return (0x0F) } } Else { If (HPAE) { Return (0x0B) } } Return (0x00) } Method (_CRS, 0, Serialized) { If (HPAE) { CreateDWordField (BUF0, \_SB.PCI0.LPCB.HPET._Y09._BAS, HPT0) If (LEqual (HPAS, 0x01)) { Store (0xFED01000, HPT0) } If (LEqual (HPAS, 0x02)) { Store (0xFED02000, HPT0) } If (LEqual (HPAS, 0x03)) { Store (0xFED03000, HPT0) } } Return (BUF0) } } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x01, // Alignment 0x08, // Length ) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x01, // Alignment 0x08, // Length ) IRQNoFlags () {8} }) Method (_CRS, 0, Serialized) { If (HPAE) { Return (BUF0) } Return (BUF1) } } Device (TIMR) { Name (_HID, EisaId ("PNP0100")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x0050, // Range Minimum 0x0050, // Range Maximum 0x10, // Alignment 0x04, // Length ) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x01, // Alignment 0x04, // Length ) IO (Decode16, 0x0050, // Range Minimum 0x0050, // Range Maximum 0x10, // Alignment 0x04, // Length ) IRQNoFlags () {0} }) Method (_CRS, 0, Serialized) { If (HPAE) { Return (BUF0) } Return (BUF1) } } So I was change my code with this one (MacPro3,1 routinne)... Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0D) }) Method (_STA, 0, NotSerialized) { If (LEqual (OSFL (), Zero)) { If (HPTE) { Return (0x0F) } } Else { If (HPTE) { Return (0x0B) } } Return (Zero) } Method (_CRS, 0, NotSerialized) { If (HPTE) { CreateDWordField (BUF0, \_SB.PCI0.SBRG.HPET._Y0D._BAS, HPT) If (LEqual (HPTS, One)) { Store (0xFED00000, HPT) } } Return (BUF0) } } Device (TIMR) { Name (_HID, EisaId ("PNP0100")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x04, // Length ) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {0} }) Method (_CRS, 0, Serialized) { If (HPTE) { Return (BUF0) } Return (BUF1) } } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x02, // Length ) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x04, // Length ) IRQNoFlags () {8} }) Method (_CRS, 0, Serialized) { If (HPTE) { Return (BUF0) } Return (BUF1) } } This working 100% in SL, however didn't fix CMOS reset in Lion... Eventually I was decide to rollback everything on my original BIOS code and this is what I'm using now... Device (HPET) { Name (_HID, EisaId ("PNP0103")) Name (CRS, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length _Y0D) }) OperationRegion (^LPCR, SystemMemory, 0xFED1F404, 0x04) Field (LPCR, AnyAcc, NoLock, Preserve) { HPTS, 2, , 5, HPTE, 1, Offset (0x04) } Method (_STA, 0, NotSerialized) { If (LEqual (OSFL (), Zero)) { If (HPTE) { Return (0x0F) } } Else { If (HPTE) { Return (0x0B) } } Return (Zero) } Method (_CRS, 0, NotSerialized) { CreateDWordField (CRS, \_SB.PCI0.SBRG.HPET._Y0D._BAS, HPT) Multiply (HPTS, 0x1000, Local0) Add (Local0, 0xFED00000, HPT) Return (CRS) } } Device (TIMR) { Name (_HID, EisaId ("PNP0100")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0040, // Range Minimum 0x0040, // Range Maximum 0x00, // Alignment 0x04, // Length ) }) } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x00, // Alignment 0x02, // Length ) IRQNoFlags () {8} }) } During this code exchange I notice two things... When I rollback: IRQNoFlags () {0} for Device (TIMR), my sound is messed up, and... IRQNoFlags () {2} for Device (PIC), breaks sleep operation... None of these changes was manage to fix CMOS reset in Lion!!! Link to comment Share on other sites More sharing options...
blackosx Posted May 20, 2011 Share Posted May 20, 2011 I wish I was smarter to figure this out. Me too But hey, lets keep looking. I'm not 100% sure that I understand the principle of the problem here and why we get the CMOS error. I know there is a checksum in the CMOS registers 0x2E and 0x2F. So are those registers being changed or the other registers (0x10->0x2D) which the checksum is calculated from? If the CMOS registers are being written to, when exactly and how? Through ACPI or a low-level kernel driver? I think OS X communicates to ACPI which in turn communicates to BIOS/CMOS. If that's correct, that means OS X (and AppleRTC) doesn't communicate directly with BIOS/CMOS. Therefore, what's missing from the ACPI tables (presumably the DSDT but could be another table?) that AppleRTC v1.4 needs? AppleRTC v1.3.1 works just fine as JUN Ho found out. Overall. I don't understand nearly enough here to nail this problem and I guess we need all the help we can get. So maybe we should find some of the devs around the community to give us their opinion? And blackosx, you are not alone… Hi Vlada Keep up the research and one day somebody will find the answer. Gutted to hear you lost the DSDT that you say fixed the error.. (I did ask you to post it ). Hopefully you can re-trace your steps and reproduce it because I haven't a clue as to what you would have done to fix it. The IRQ's have been know to cause problems with hackintosh so most DSDT's have them removed. See here for example. I'm going away for a week tomorrow morning so I won't be able to do any further testing until I get back. Link to comment Share on other sites More sharing options...
albert E Posted May 22, 2011 Share Posted May 22, 2011 Heh, nice but I'd rather prefer that we find proper solution… Good catch… I was become aware of that today, when I was left my room on 15 minutes… As for SL auto-sleep issue, I’m using Please Sleep… Well, I don't know… First I was thinking that this is ICH9 chipset error only, but obviously it's not… It catches ICH10 too… Then I was suspect that perhaps Device (EHCI) could be related with this little issue, but again I was wrong… After I was made a couple of tests it appears eventually, that is not the problem (or at least not in my case)… I really don't have a clue now, because it's seems that there is no pattern or at least I can't see any. Maybe we should put on pile all elements from the DSDT code related with sleep and then start from there… Man, it would be nice if we could locate same motherboard in two different computers, where one haves CMOS error problem and other one don’t. Then we could just simply compare DSDT-s from both computers and easily locate what’s causing all this… Put dsdt.aml in the root directory Link to comment Share on other sites More sharing options...
Vlada. Posted May 22, 2011 Share Posted May 22, 2011 Put dsdt.aml in the root directory Eh? What's that gonna change? Link to comment Share on other sites More sharing options...
rayap Posted May 22, 2011 Author Share Posted May 22, 2011 Hi blackosx "So to summise at this point: This all looks normal and doesn't really help here. Something is changing the CMOS data somehow?" I think these dump utilites are not reading the cmos correctly beyond the first 64 bytes. In your results the top half is a mirror of the second half. i was able to read using 'DosBox" and 'CmosDos' the 128 bytes where the halfs are different. With Windows XP under Parallels we can read 256 bytes. The cmos reading in Windows XP machine directly gives good and valid values for the whole of the standard bank of 128 bytes. The values in the second half of the standard bank changes. if you amend your cmos settings - say enabling startup alarm. But for DosBox or XP in Parallels, similar changes in cmos settings are not reflected at all in the cmos readings. They appear as constant. Even if we schedule a startup in Enery Saver settings, there is no change in the particular cmos locations. Either we cannot read these cmos locations with our present means or these are kept elsewhere in a real mac. An osx utilty to directly dump cmos will help. CMOSTimer: http://www.boraxsoft.de/CMOSTimer_eng.html Link to comment Share on other sites More sharing options...
Time2Retire Posted May 24, 2011 Share Posted May 24, 2011 What you want to do is to locate the write action that is causing the CMOS reset. For this I have a few test in mind that need to be done with Apple RTC v1.4 Do it one at a time. Write down what you did (blackosx ) and return here with iyr findings. Oh. You will probably find two of each (one for 32-bit and one for 64-bit code) so patch them both! Step-1: Open AppleRTC and search for the following byte combination: AppleRTCUserClient::clientWriteBytes(void*, void*, void*, void*, void*, void*) +0 00000560 55 pushl %ebp +1 00000561 89e5 movl %esp,%ebp +3 00000563 53 pushl %ebx +4 00000564 57 pushl %edi +5 00000565 56 pushl %esi +6 00000566 83ec1c subl $0x1c,%esp +9 00000569 837d1000 cmpl $0x00,0x10(%ebp) Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble. Step-2: Search for the following byte combination: AppleRTC::rtcWrite(unsigned int, unsigned char) +0 00000b6a 55 pushl %ebp +1 00000b6b 89e5 movl %esp,%ebp +3 00000b6d 57 pushl %edi +4 00000b6e 56 pushl %esi +5 00000b6f 83ec20 subl $0x20,%esp +8 00000b72 8b750c movl 0x0c(%ebp),%esi Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble. Step-3: Search for the following byte combination: AppleRTC::rtcWriteBytes(unsigned char*, unsigned int, unsigned int) +0 00002d7a 55 pushl %ebp +1 00002d7b 89e5 movl %esp,%ebp +3 00002d7d 53 pushl %ebx +4 00002d7e 57 pushl %edi +5 00002d7f 56 pushl %esi +6 00002d80 83ec3c subl $0x3c,%esp +9 00002d83 833de450000000 cmpl $0x00,0x000050e4 Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble. Step-4: Search for the following byte combination: AppleRTC::rtcWriteBytesAndCRC(unsigned char*, unsigned int, unsigned int) +0 00002ee6 55 pushl %ebp +1 00002ee7 89e5 movl %esp,%ebp +3 00002ee9 57 pushl %edi +4 00002eea 56 pushl %esi +5 00002eeb 83ec10 subl $0x10,%esp +8 00002eee 8b4514 movl 0x14(%ebp),%eax Replace the first byte (55) with C3 and save the file. Check if this is the one that is causing trouble. Note: C3 is the opcode for ret(urn). No time to do this but this is a start. Good luck! Link to comment Share on other sites More sharing options...
rayap Posted May 25, 2011 Author Share Posted May 25, 2011 Hi DHP you are a clever fella. I only made the change for the rtcWriteBytesAndCRC in 64-bit. Tested with rtc register length of 0x04 and 0x08. Everything went well. No CMOS resets for the old problem of restarts which required a register length of 0x02 or sleep in Lion of this topic. But what's next Link to comment Share on other sites More sharing options...
Time2Retire Posted May 25, 2011 Share Posted May 25, 2011 Right. Function rtcWriteBytesAndCRC is called from two places (read functions) and we need to narrow the scope to one, so please do this: 1.) Backup your current version. 2.) Restore the original / unmodified file. 3.) Follow step-1 to block clientWriteBytes. And if that doesn't work, then I know where to look next aka function setHibernateState which is where I think {censored}e happens Thanks for testing this! Link to comment Share on other sites More sharing options...
rayap Posted May 25, 2011 Author Share Posted May 25, 2011 Done that in 64-bit and the cmos reset reappears with rtc reg length 0x02. Looks like an extra call from setHibernateState to rtcWriteBytesAndCRC in this version of the kext. Hope this suffice. Rgds. Link to comment Share on other sites More sharing options...
Time2Retire Posted May 25, 2011 Share Posted May 25, 2011 Done that in 64-bit and the cmos reset reappears with rtc reg length 0x02. Looks like an extra call from setHibernateState to rtcWriteBytesAndCRC in this version of the kext. Hope this suffice. Rgds. Ok so this appears to be done in function setHibernateState and thus there are a couple of things that you can do. Step-1: Search for this and let it ret(urn) by replacing 55 with C3 AppleRTC::setHibernateState(unsigned long) +0 00002f26 55 pushl %ebp +1 00002f27 89e5 movl %esp,%ebp +3 00002f29 53 pushl %ebx +4 00002f2a 57 pushl %edi +5 00002f2b 56 pushl %esi +6 00002f2c 83ec1c subl $0x1c,%esp +9 00002f2f 8b7508 movl 0x08(%ebp),%esi If returning there works, then we know that we're at the right spot. I checked v1.3 and there I see two write calls, but in v1.4 I see three of them. My guess would be that it is either the last one you need to change, or the one before that. Replacing the calll with nop's (no operation / 90) to see if that works (and for which one). One of the write operations reads: "RTC: Restored entire RTC RAM\n" so that might be the one Note well that bin-patching AppleRTC might in the end not be required, but that is something to be seen at a later stage. Good luck! Link to comment Share on other sites More sharing options...
rayap Posted May 26, 2011 Author Share Posted May 26, 2011 Hi DHP Blocking setHibernateState did not give desired result. Decided to go downstream. When blocking rtcWriteBytesAndCRC was looking good, went on to blocking updateChecksum. Consequently only blocking the Call ( with nops' as you suggested) from rtcRecordTracePoint to updateChecksum gave desired result. With rtc reg length 0x08. restarts after sleep do not gives cmos reset. Is this helpful at all? So what's next? Edit: Don't know how to replace equivalent jmp in v1.3.1 Used C3 and nops' Update: 1. Blocking the jmp from recordTracePointHandler to rtcRecordTracePoint in both versions 1.3.1 & 1.4 of AppleRTC resolves the RTC register length cmos resets. 2. Blocking both the call and jmp from setAlarmEnable to rtcRecordTracePoint in ver1.4 of AppleRTC resolves the cmos rests after sleep. Thus far all seems well. Link to comment Share on other sites More sharing options...
Recommended Posts