dmazar Posted February 19, 2012 Share Posted February 19, 2012 Oh, great Although a bit risky - it still should be checked by hand on new version, I believe. But, the best option so far. Not sure if I understand what do you mean with "addresses from otool doesn't have 0F 30". Do you mean that when you take offset with lipo and add it to address from tool, it does not match offset of this instruction in file? That position does not contain 0f 03? Link to comment Share on other sites More sharing options...
oldnapalm Posted February 19, 2012 Share Posted February 19, 2012 Yes, that's it, if I run otool with -arch i386 and add i386 offset from lipo, the position does not contain 0F 30. Link to comment Share on other sites More sharing options...
jazzyguy Posted February 19, 2012 Share Posted February 19, 2012 This script searches for wrmsr (preceded by movl $0x000000e2,%ecx) in otool output, so it should work for any version. I tested only with 10.7.3 and 10.8. Thanks to el coniglio for the script. Usage: Search for wrmsr perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement Patch sudo perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement patch Important: don't patch a file that has already been patched, or unnecessary patching will be done. Any ideas about i386? The wrmsr addresses from otool doesn't have 0F 30. How does it work in 32 bit? Will this always work? What if there was something else set to 0xe2, then the address changes and then the next line down is a 0f30? Or am I mistaken? Link to comment Share on other sites More sharing options...
dmazar Posted February 19, 2012 Share Posted February 19, 2012 Yes, that's it, if I run otool with -arch i386 and add i386 offset from lipo, the position does not contain 0F 30. I'm not sure if I got it right, but I think it works like this ... 10.7.3 in example: > lipo -detailed_info AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement Fat header in: AppleIntelCPUPowerManagement fat_magic 0xcafebabe nfat_arch 2 architecture x86_64 cputype CPU_TYPE_X86_64 cpusubtype CPU_SUBTYPE_X86_64_ALL offset 4096 size 191440 align 2^12 (4096) architecture i386 cputype CPU_TYPE_I386 cpusubtype CPU_SUBTYPE_I386_ALL offset 196608 ====> OFFarch size 213540 align 2^12 (4096) > otool -l -arch i386 AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement AppleIntelCPUPowerManagement: Load command 0 cmd LC_SEGMENT cmdsize 600 segname vmaddr 0x00000000 vmsize 0x00028034 fileoff 756 filesize 154412 maxprot 0x00000003 initprot 0x00000003 nsects 8 flags 0x0 Section sectname __text segname __TEXT addr 0x00000000 ====> VAsect size 0x0001b294 offset 756 ====> OFFsect align 2^4 (16) reloff 155168 nreloc 3648 flags 0x00000000 reserved1 0 reserved2 0 Section sectname __const segname __TEXT addr 0x0001b2a0 size 0x00000db4 offset 112020 align 2^4 (16) reloff 184352 nreloc 703 flags 0x00000000 reserved1 0 reserved2 0 ... ... VA = address from otool disassembled output OFF = offset of this instruction in file - this is what you need OFFarch = offset of architecture speciffic binary in Fat file (in lipo output) OFFsect = offset of segment __TEXT section __text (contains code) inside architecture specific binary (in otool output) VAsect = starting virtual address of segment __TEXT section __text (in otool output) Then: OFF = OFFarch + OFFsect + VA - VAsect The same logic is for x86_64. Link to comment Share on other sites More sharing options...
oSxFr33k Posted February 19, 2012 Share Posted February 19, 2012 This script searches for wrmsr (preceded by movl $0x000000e2,%ecx) in otool output, so it should work for any version. I tested only with 10.7.3 and 10.8. Thanks to el coniglio for the script. Usage: Search for wrmsr perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement Patch sudo perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement patch Important: don't patch a file that has already been patched, or unnecessary patching will be done. Any ideas about i386? The wrmsr addresses from otool doesn't have 0F 30. How does it work in 32 bit? Works great thanks very much. I verified with manually patched 10.7.2, 10.7.3 and 10.8!! I am interested to in patching for 32 bit since I mentioned once before there are rare moments I have to boot into 32 bit mode to use my Sprint Modem Software for when I am on call. I also want to reiterate that the one address I mentioned here http://www.insanelym...dpost&p=1797998 if left unpatched, does not cause a kernel panic for either 10.7.2 nor 10.7.3. This type of address is not in 10.8 Is there a reason for this? Can someone try it on there Asus P8 maybe its just my Asus G74SX Laptop motherboard that is not affected. It should kernel panic in theory and it doesn't!! Thanks again for keeping this project alive Link to comment Share on other sites More sharing options...
oldnapalm Posted February 19, 2012 Share Posted February 19, 2012 Will this always work? Quoting dmazar, "it still should be checked by hand on new version". What if there was something else set to 0xe2, then the address changes and then the next line down is a 0f30? It checks for "movl $0x000000e2,%ecx" so if something else is set to 0xe2 it won't matter. I think it would be a problem if ecx value has changed before wrmsr, but that would be difficult to verify. @dmazar, thanks, I missed that, in x86_64 addr and offset from otool -l coincides addr 0x0000000000000500 offset 1280 Link to comment Share on other sites More sharing options...
oldnapalm Posted February 20, 2012 Share Posted February 20, 2012 I am interested to in patching for 32 bit since I mentioned once before there are rare moments I have to boot into 32 bit mode to use my Sprint Modem Software for when I am on call. Please download script again and test, added i386 patch. Thanks again for dmazar help. Link to comment Share on other sites More sharing options...
jazzyguy Posted February 20, 2012 Share Posted February 20, 2012 Quoting dmazar, "it still should be checked by hand on new version". It checks for "movl $0x000000e2,%ecx" so if something else is set to 0xe2 it won't matter. I think it would be a problem if ecx value has changed before wrmsr, but that would be difficult to verify. @dmazar, thanks, I missed that, in x86_64 addr and offset from otool -l coincides addr 0x0000000000000500 offset 1280 Gotcha. Thanks for the explanation. Link to comment Share on other sites More sharing options...
oSxFr33k Posted February 20, 2012 Share Posted February 20, 2012 Please download script again and test, added i386 patch. Thanks again for dmazar help. For some reason the second part of the perl script does not display patched when done it just runs through like the initial step so it never patched it. I tried it in both 32 and 64 bit and it panics. I will run the patch again to see but I am sure it does not patch it when you run it the second time with patch after the AICPUPM file name. osxfr33ks-MacBook-Pro:test osxfr33k$ perl AICPMPatch.pl AppleIntelCPUPowerManagement AppleIntelCPUPowerManagement arch: x86_64 found wrmsr at 0xa11a found wrmsr at 0xa1e2 found wrmsr at 0xa260 found wrmsr at 0xa2a9 found wrmsr at 0xab64 found wrmsr at 0xac16 found wrmsr at 0xacf4 found wrmsr at 0xb340 found wrmsr at 0x1170a found wrmsr at 0x117e8 arch: i386 found wrmsr at 0x393e7 found wrmsr at 0x39481 found wrmsr at 0x394dd found wrmsr at 0x3950e found wrmsr at 0x39db6 found wrmsr at 0x39e30 found wrmsr at 0x39efa found wrmsr at 0x3a4d0 found wrmsr at 0x40606 found wrmsr at 0x406d0 osxfr33ks-MacBook-Pro:test osxfr33k$ sudo perl AICPMPatch.pl AppleIntelCPUPowerManagement patch Password: AppleIntelCPUPowerManagement arch: x86_64 found wrmsr at 0xa11a found wrmsr at 0xa1e2 found wrmsr at 0xa260 found wrmsr at 0xa2a9 found wrmsr at 0xab64 found wrmsr at 0xac16 found wrmsr at 0xacf4 found wrmsr at 0xb340 found wrmsr at 0x1170a found wrmsr at 0x117e8 arch: i386 found wrmsr at 0x393e7 found wrmsr at 0x39481 found wrmsr at 0x394dd found wrmsr at 0x3950e found wrmsr at 0x39db6 found wrmsr at 0x39e30 found wrmsr at 0x39efa found wrmsr at 0x3a4d0 found wrmsr at 0x40606 found wrmsr at 0x406d0 osxfr33ks-MacBook-Pro:test osxfr33k$ Link to comment Share on other sites More sharing options...
jazzyguy Posted February 20, 2012 Share Posted February 20, 2012 I just ran this: sudo perl /Users/jazzyguy/Desktop/AICPMPatch.pl /Users/jazzyguy/Desktop/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement --patch with the original and the second (I put a vanilla kext there in between) and it just said patching.... once for the original script, and nothing for the first. That's not correct is it? Link to comment Share on other sites More sharing options...
rcork Posted February 20, 2012 Share Posted February 20, 2012 Here are the locations in the 32-bit section of the instructions that need patching (for 10.7.3). The easiest thing would be to update dmazar's perl script definition file to include these addresses as well 000393E7 00039481 000394DD 0003950E 00039DB6 00039E30 00039EFA 0003A4D0 00040606 000406D0 Link to comment Share on other sites More sharing options...
oSxFr33k Posted February 20, 2012 Share Posted February 20, 2012 Would this be in the same section "Section64(__TEXT__,text)/Assembly under the Kernel Extension (x86_64)"? It's probably under the Object (x86) Section (__TEXT,__text). No assembly section to play with though? Ah oldnapalm also changed the script I did not notice the --patch instead of what he had before as patch. I just assumed he changed the perl script not the actual user command line. Anyways, I ran it as 64 bit no issue but the 32 bit mode panics. Link to comment Share on other sites More sharing options...
oldnapalm Posted February 20, 2012 Share Posted February 20, 2012 For 10.7.3 without --patch arch: x86_64 found wrmsr at 0xa11a found wrmsr at 0xa1e2 found wrmsr at 0xa260 found wrmsr at 0xa2a9 found wrmsr at 0xab64 found wrmsr at 0xac16 found wrmsr at 0xacf4 found wrmsr at 0xb340 found wrmsr at 0x1170a found wrmsr at 0x117e8 arch: i386 found wrmsr at 0x393e7 found wrmsr at 0x39481 found wrmsr at 0x394dd found wrmsr at 0x3950e found wrmsr at 0x39db6 found wrmsr at 0x39e30 found wrmsr at 0x39efa found wrmsr at 0x3a4d0 found wrmsr at 0x40606 found wrmsr at 0x406d0 For 10.7.3 with --patch arch: x86_64 found wrmsr at 0xa11a, patched found wrmsr at 0xa1e2, patched found wrmsr at 0xa260, patched found wrmsr at 0xa2a9, patched found wrmsr at 0xab64, patched found wrmsr at 0xac16, patched found wrmsr at 0xacf4, patched found wrmsr at 0xb340, patched found wrmsr at 0x1170a, patched found wrmsr at 0x117e8, patched arch: i386 found wrmsr at 0x393e7, patched found wrmsr at 0x39481, patched found wrmsr at 0x394dd, patched found wrmsr at 0x3950e, patched found wrmsr at 0x39db6, patched found wrmsr at 0x39e30, patched found wrmsr at 0x39efa, patched found wrmsr at 0x3a4d0, patched found wrmsr at 0x40606, patched found wrmsr at 0x406d0, patched Looks correct. 1 Link to comment Share on other sites More sharing options...
oSxFr33k Posted February 20, 2012 Share Posted February 20, 2012 @oldnapalm, Read 1 up from your post. It panics in 32 bit mode Link to comment Share on other sites More sharing options...
jazzyguy Posted February 20, 2012 Share Posted February 20, 2012 Is it neccessary to run the script without --patch, then re run it with --patch? Link to comment Share on other sites More sharing options...
oldnapalm Posted February 20, 2012 Share Posted February 20, 2012 @jazzyguy, no, you can run with --patch directly (run without --patch just if you want to list offsets without patching). @oSxFr33k, i386 offsets are the same posted by rcork above (found by hand), so it should be correct. Maybe in i386 something else is needed, or the patcher if failing (run with sudo if you are patching kext in /S/L/E directly and check offsets by hand). Link to comment Share on other sites More sharing options...
joe2108 Posted February 20, 2012 Share Posted February 20, 2012 what happen with mine /Users/j03d0tn3t/Desktop/patch/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement arch: x86_64 arch: i386 or j03d0tn3ts-Mac-Pro:~ j03d0tn3t$ sudo perl /Users/j03d0tn3t/Desktop/patch/AICPMPatch.pl /Users/j03d0tn3t/Desktop/patch/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement --patch /Users/j03d0tn3t/Desktop/patch/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement arch: x86_64 arch: i386 Just blank.. no texts or anything Link to comment Share on other sites More sharing options...
oldnapalm Posted February 20, 2012 Share Posted February 20, 2012 You need otool, read discussion in last pages. You can use dmazar patcher, it has verified offsets for each version, so otool is not needed. Link to comment Share on other sites More sharing options...
joe2108 Posted February 20, 2012 Share Posted February 20, 2012 this is my folder when patch .. otool include or something missing or can i download otool somewhere to test Link to comment Share on other sites More sharing options...
oldnapalm Posted February 20, 2012 Share Posted February 20, 2012 Put otool in /usr/bin or edit script and replace otool by ./otool Link to comment Share on other sites More sharing options...
joe2108 Posted February 20, 2012 Share Posted February 20, 2012 oke... thank.. but my question... I still get error P-State error on 4 core Using AppleIntelCPUPowerManagement.kext Patched on 10.8 using your script and dmazar patcher 2/21/12 1:19:53.000 AM kernel: P-State Stepper Error 18 at step 2 on CPU 1 2/21/12 1:19:53.000 AM kernel: P-State Stepper Error 18 at step 2 on CPU 2 2/21/12 1:19:53.000 AM kernel: P-State Stepper Error 18 at step 2 on CPU 3 2/21/12 1:19:53.000 AM kernel: P-State Stepper Error 18 at step 2 on CPU 0 and bad Geekbench score just about 4000 or multiplier just run on x16 only without null but when I use AppleIntelCPUPowerManagement.kext 10.7.3 on ML P-State oke & good benchmark about 12000 more.. or IntelSpeedStep it's ok without null something wrong with my patch or ?? sorry my bad english Link to comment Share on other sites More sharing options...
oldnapalm Posted February 21, 2012 Share Posted February 21, 2012 Same that was reported by slave-zeo Upon booting into the OS I loaded MSRDumper and opened up the console and let the system run for about 15 minuets. Saddly, all I got was one state and it was 16. I would asume my cpu was running at the bare minimum. Maybe 10.8 needs different patching, I have no idea, don't even have hardware to test this. Link to comment Share on other sites More sharing options...
rcork Posted February 21, 2012 Share Posted February 21, 2012 Same that was reported by slave-zeo Maybe 10.8 needs different patching, I have no idea, don't even have hardware to test this. @slave-zeo What CPU are you using? Do you have PR section in your DSDT (if you're even using one)? Can you send me your DSDT? I'll try putting 10.8 on another drive and see if i get all my p-states (i currently get 16, 23, 34, 35, 36, 37, 38) Link to comment Share on other sites More sharing options...
rcork Posted February 21, 2012 Share Posted February 21, 2012 Not sure if you guys have seen this but it may be a better alternative to patching http://www.tonymacx86.com/viewtopic.php?f=14&t=49340 I'm going to try the bios for my P8Z68-V and see if it works Link to comment Share on other sites More sharing options...
joe2108 Posted February 21, 2012 Share Posted February 21, 2012 I'll be the first to admit I don't understand about 75% of what you folks are saying BUT what I can say is that I tried the above linked kext (AppleIntelCPUPowerManagement.kext-PATCHED.zip) and my Mt. Lion 10.8 system booted without the need for the NullCPU kext. Upon booting into the OS I loaded MSRDumper and opened up the console and let the system run for about 15 minuets. Saddly, all I got was one state and it was 16. I would asume my cpu was running at the bare minimum. Still, this is very promising. Thanks for the patched kext! Use ICPUM .kext from 10.7.3 first... try it 1 Link to comment Share on other sites More sharing options...
Recommended Posts