571 replies to this topic

[oldnapalm]

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

[oldnapalm]

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.

[jazzyguy]

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.

[oSxFr33k]

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 AppleIntelCPUPowerManagementAppleIntelCPUPowerManagementarch: x86_64found wrmsr at 0xa11afound wrmsr at 0xa1e2found wrmsr at 0xa260found wrmsr at 0xa2a9found wrmsr at 0xab64found wrmsr at 0xac16found wrmsr at 0xacf4found wrmsr at 0xb340found wrmsr at 0x1170afound wrmsr at 0x117e8arch: i386found wrmsr at 0x393e7found wrmsr at 0x39481found wrmsr at 0x394ddfound wrmsr at 0x3950efound wrmsr at 0x39db6found wrmsr at 0x39e30found wrmsr at 0x39efafound wrmsr at 0x3a4d0found wrmsr at 0x40606found wrmsr at 0x406d0osxfr33ks-MacBook-Pro:test osxfr33k$ sudo perl AICPMPatch.pl AppleIntelCPUPowerManagement patchPassword:AppleIntelCPUPowerManagementarch: x86_64found wrmsr at 0xa11afound wrmsr at 0xa1e2found wrmsr at 0xa260found wrmsr at 0xa2a9found wrmsr at 0xab64found wrmsr at 0xac16found wrmsr at 0xacf4found wrmsr at 0xb340found wrmsr at 0x1170afound wrmsr at 0x117e8arch: i386found wrmsr at 0x393e7found wrmsr at 0x39481found wrmsr at 0x394ddfound wrmsr at 0x3950efound wrmsr at 0x39db6found wrmsr at 0x39e30found wrmsr at 0x39efafound wrmsr at 0x3a4d0found wrmsr at 0x40606found wrmsr at 0x406d0osxfr33ks-MacBook-Pro:test osxfr33k$

[jazzyguy]

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?

[rcork]

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

[oSxFr33k]

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.

[oldnapalm]

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.

[oSxFr33k]

@oldnapalm,

Read 1 up from your post. It panics in 32 bit mode

[jazzyguy]

Is it neccessary to run the script without --patch, then re run it with --patch?

[oldnapalm]

@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).

[joe2108]

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

Attached Files

•  Screen Shot 2012-02-20 at 10.53.00 PM.png   29.7KB   93 downloads

[oldnapalm]

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.

[joe2108]

this is my folder when patch .. otool include or something missing

or can i download otool somewhere to test

Attached Files

•  Screen Shot 2012-02-20 at 11.07.58 PM.png   6.82KB   19 downloads

[oldnapalm]

Put otool in /usr/bin or edit script and replace otool by ./otool

[joe2108]

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

 speedstep.png   43.53KB   147 downloads

something wrong with my patch or ??

sorry my bad english

[oldnapalm]

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.

[rcork]

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)

[rcork]

Not sure if you guys have seen this but it may be a better alternative to patching

http://www.tonymacx8...hp?f=14&t=49340

I'm going to try the bios for my P8Z68-V and see if it works

[joe2108]

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