SpeedStepper (now supports Mountain Lion 10.8.3)

[gerard71]

From what I have read this is the most tedious and difficult thing to figure out how to patch. AT least that is what flAked had mentioned in a couple of posts. It would be nice to pass this along to someone who could continue the work and not just leave it go.

 

If so I will basically say my Asus Laptop G74SX will have an end of life with either 10.7.2 or 10.7.3 if I can get this new patch to work.

 

I can deal with that I suppose unless we can figure out a way to unlock our EFI Bios and make it an option to turn this on/off.

 

you can continue to update even if there is no patch simply replace AppleIntelCPUPowerManagement.kextAppleIntelCPUPowerManagementClient.kext and by those of 10.7.4 to version 10.7.3

[x1a0]

Hi,

 

After using MSRDumper.kext, in the kernel.log I can see it's always:

 

Feb 13 22:22:26 Zhangs-iMac kernel[0]: MSRDumper CoreMulti(34)
Feb 13 22:22:26 Zhangs-iMac kernel[0]: MSRDumper PStatesReached: 34

 

Does this mean SpeedStep is not working?

 

I tried to apply the patch for 10.7.2 and it seemed not work.

 

I am running 10.7.3 on a Asus P8P67 Deluxe board. i7-2600K CPU.

 

Thanks!

[westwaerts]

Hi,

 

After using MSRDumper.kext, in the kernel.log I can see it's always:

 

Feb 13 22:22:26 Zhangs-iMac kernel[0]: MSRDumper CoreMulti(34)
Feb 13 22:22:26 Zhangs-iMac kernel[0]: MSRDumper PStatesReached: 34

 

Does this mean SpeedStep is not working?

 

I tried to apply the patch for 10.7.2 and it seemed not work.

 

I am running 10.7.3 on a Asus P8P67 Deluxe board. i7-2600K CPU.

 

Thanks!

 

if you run it for a minute, you should see more p-states, but only one is no speedstep.

look if AppleLCP is loaded. i have also a SSDT in Extra for my i7-2600.

[x1a0]

if you run it for a minute, you should see more p-states, but only one is no speedstep.

look if AppleLCP is loaded. i have also a SSDT in Extra for my i7-2600.

 

It's been running for a while and it's always 34. I think SpeedStep is not working at all.

 

After running `kextstat` I can see:

76    0 0xffffff7f8140e000 0x3000     0x3000     com.apple.driver.AppleLPC (1.5.3) <9 5 4 3>

 

So I guess that means AppleLPC is loaded?

 

Is there a patch for AICPUPM (10.7.3)?

[Pluskat5000Schiffe]

Hi Guys,

 

I upgraded this evening to 10.7.3 too. Although it was an easy upgrade I needed to patch the AppleIntelCpuPowerManagement.Kext from 10.7.3 nothing special would you think. But the strange thing is I don't have an Asus Motherboard but I have a HP8560W Elitebook with SandyBridge (QM67). Without this speed stepper 10.7.3 patch I got Kernel Panic. So it has results for all SandyBridge Systems I'll think. Maybe my conclusion is to simply explained but it fixed my KP. (Awesome performance :-) 9550 geekbench with 2630QM )

[jazzyguy]

It shouldn't be too hard to figure out. I believe all he is doing is searching in the binary for the opcode for the WRMSR and replacing with a NOOP. (http://siyobik.info/...struction/WRMSR). Once work slows down a bit i was going to start researching and put together an approach for patching. It would be much easier if he just release the source code to his current patcher :wink2:

It shouldn't be too hard to figure out. I believe all he is doing is searching in the binary for the opcode for the WRMSR and replacing with a NOOP. (http://siyobik.info/...struction/WRMSR). Once work slows down a bit i was going to start researching and put together an approach for patching. It would be much easier if he just release the source code to his current patcher :wink2:

 

I wonder, is there a way to make this happen dynamically?

 

I don't know what WRMSR or NOOP are, but is there a way to make a script or something that has all the possible ones so it can automatically happen for us?

[jazzyguy]

Am I right in guessing that ML will require the same process?

[oSxFr33k]

It shouldn't be too hard to figure out. I believe all he is doing is searching in the binary for the opcode for the WRMSR and replacing with a NOOP. (http://siyobik.info/...struction/WRMSR). Once work slows down a bit i was going to start researching and put together an approach for patching. It would be much easier if he just release the source code to his current patcher :wink2:

 

I still do not think its that easy. I searched for WRMSR text etc and came up with nothing unless that is because the binary is already compiled and as such that its no longer a text WRMSR. Actually I think when its compiled maybe its the value 0f30? See below:

 

http://www.insanelym...dpost&p=1771283

 

Maybe finding the correct Hex string would require some kinda of Debugger and Disassembler Software. With a Debugger it would have to be an application that runs so you can stop it at any point, like after clicking a button you want to know where it lands in the disassembled script. How in the world could you debug this at the Bios level unless you run an emulator? Even with the right tools its going to be difficult. I find a lot of instances of 0F30's all over the place and who knows which is WRMSR and even if it is WRMSR how would you know to noop it or not using 9090?

[jazzyguy]

So does anyone know how to do this with ML? Or are we stuck now?

[oSxFr33k]

What is ML?

[jazzyguy]

Mountain Lion

[jazzyguy]

Oh guys- couldn't we compare the original binarys to the edited ones and see the changes?

 

Perhaps its easier then you would think?

[dmazar]

It would be much easier if he just release the source code to his current patcher :wink2:

Not really. If I understood correctly, he is replacing wrmsr with 2 nop - ones that are writing to $e2 register. It's easy to find wrmsr instructions, but not so easy to find ones writing to $e2. At least not to a simple program.

So, he is checking them all "by hand" in disassembled code and patcher only contains those wrmsr addresses found "by hand".

Patcher source code would not help you much. Each new AICPUPM requires manual processing first.

[rcork]

Not really. If I understood correctly, he is replacing wrmsr with 2 nop - ones that are writing to $e2 register. It's easy to find wrmsr instructions, but not so easy to find ones writing to $e2. At least not to a simple program.

So, he is checking them all "by hand" in disassembled code and patcher only contains those wrmsr addresses found "by hand".

Patcher source code would not help you much. Each new AICPUPM requires manual processing first.

I agree now that getting the source code to his current patcher is not going to help much. I believe he has manually gone through the binary and figured out where each instruction is that needs to be replaced. His code is probably just patching those specific areas, nothing more. That's the easy part. The hard part is figuring out which WRMSR instructions need to be patched and where in the file they are.

 

I haven't had anytime to dig much deeper but in essence, we need to find where we are moving 0x000000E2 into register ECX and then where the very next WRMSR instruction is. These need to get patched to NOPs.

[dmazar]

I haven't had anytime to dig much deeper but in essence, we need to find where we are moving 0x000000E2 into register ECX and then where the very next WRMSR instruction is. These need to get patched to NOPs.<br>

 

You can start with MachOView http://sourceforge.net/projects/machoview/ if you want.

 

For example, on Lion 10.7.3 AICPUPM flAked's patcher will give you:

 

Searching for wrmsr #0: a11a

Searching for wrmsr #1: a1e2

Searching for wrmsr #2: a260

Searching for wrmsr #3: a2a9

Searching for wrmsr #4: ab64

Searching for wrmsr #5: ac16

...

a11a, a1e2 .. are addresses that are patched.

 

You can open AICPUPM.kext/Contents/MacOS/AICPUPM in MAchOView and then select

Fat Binary/Kernel Extension (X86_64)/Section64 (__TEXT,__text)/Assembly

and check what's in there.

Open the original one and patched one in the same way and compare them at addresses that are patched. Make sure RAW option is checked - MachOView will give you positions/offsets of instructions inside the file.

You are looking for something like:

B9E2000000 movl $0x000000e2, %ecx

(possible instructions in between)

0F30 wrmsr

 

You can also open each file in some hex editor and check each patch address in there in parallel with MachOView.

 

That's good to do to get the feeling of what flAked is doing.

 

For patching, MachOView will not be enough. Saving and searching disassembled code does not work. But you can use otool:

otool -tV -arch x86_64 AICPUPM.kext/Contents/MacOS/AICPUPM > tmp.asm

and then search through tmp.asm in text editor.

One note: addresses here are, hm ... do not know how to say it simply and still be correct ... maybe it's easiest to compare them with MachOView offsets - so just add some constant to them (in above example for 10.7.3 it is hex 0x1000) to get positions of each instruction in the file.

 

Once you know what wrmsr you want to patch, you just need to open the file in hex editor and replace your 0F30 (wrmsr) with 9090 (2 nops).

 

But before patching, it would probably be good to go through all above with some other version of AIPCUPM (getting addresses from flAked's patcher, comparing original with patched AICPUMP on each address).

And, probably, double check every wrmsr (around 50 of them) if %ecx register is set to 0xe2 (just 10 of them in 10.7.3).

[rcork]

You can start with MachOView http://sourceforge.net/projects/machoview/ if you want.

 

For example, on Lion 10.7.3 AICPUPM flAked's patcher will give you:

 

Searching for wrmsr #0: a11a

Searching for wrmsr #1: a1e2

Searching for wrmsr #2: a260

Searching for wrmsr #3: a2a9

Searching for wrmsr #4: ab64

Searching for wrmsr #5: ac16

...

a11a, a1e2 .. are addresses that are patched.

 

You can open AICPUPM.kext/Contents/MacOS/AICPUPM in MAchOView and then select

Fat Binary/Kernel Extension (X86_64)/Section64 (__TEXT,__text)/Assembly

and check what's in there.

Open the original one and patched one in the same way and compare them at addresses that are patched. Make sure RAW option is checked - MachOView will give you positions/offsets of instructions inside the file.

You are looking for something like:

B9E2000000 movl $0x000000e2, %ecx

(possible instructions in between)

0F30 wrmsr

 

You can also open each file in some hex editor and check each patch address in there in parallel with MachOView.

 

That's good to do to get the feeling of what flAked is doing.

 

For patching, MachOView will not be enough. Saving and searching disassembled code does not work. But you can use otool:

otool -tV -arch x86_64 AICPUPM.kext/Contents/MacOS/AICPUPM > tmp.asm

and then search through tmp.asm in text editor.

One note: addresses here are, hm ... do not know how to say it simply and still be correct ... maybe it's easiest to compare them with MachOView offsets - so just add some constant to them (in above example for 10.7.3 it is hex 0x1000) to get positions of each instruction in the file.

 

Once you know what wrmsr you want to patch, you just need to open the file in hex editor and replace your 0F30 (wrmsr) with 9090 (2 nops).

 

But before patching, it would probably be good to go through all above with some other version of AIPCUPM (getting addresses from flAked's patcher, comparing original with patched AICPUMP on each address).

And, probably, double check every wrmsr (around 50 of them) if %ecx register is set to 0xe2 (just 10 of them in 10.7.3).

 

This saved me a lot of time researching. I can easily see now each of the places that need to be patched and verified against the 10.7.3 patched version. Shouldn't be too difficult to manually do this when a new version is released. However, coming up with a dynamic method is a different story.

[jazzyguy]

Well if dynamic were to be possible, that'd be amazing, but I (don't really) get how complicated this is.

 

Want to test out this new ability on the Mountain Lion version?

[oSxFr33k]

@dmazar

 

 

Thanks for that information I am going to try this on my own since I have used debuggers and dissemblers in the past to try and make well I won't say but I am sure you got the picture. What is otool is that part of xcode utils?

 

I use IDA Pro and since Current MAcs are Intel x86, I have to assume I can use it with IDA Pro or is that overkill?

 

Thanks again!!

[rcork]

Well if dynamic were to be possible, that'd be amazing, but I (don't really) get how complicated this is.

 

Want to test out this new ability on the Mountain Lion version?

Send me the AICPM kext from Mountain Lion and i'll take a shot

[ricola]

Send me the AICPM kext from Mountain Lion and i'll take a shot

 

Here .. AppleIntelCPUPowerManagement.kext.zip

[oldnapalm]

@dmazar, thanks, great guide.

 

For patching, MachOView will not be enough. Saving and searching disassembled code does not work.

I used "print", saved as PDF and searched for $0x000000e2, then for 0F30 after it. Found these in 10.8 AICPUPM, if anyone else is looking into this we can compare

0003BF13 0F30 wrmsr
0003C7A5 0F30 wrmsr
0003C830 0F30 wrmsr
0003C87D 0F30 wrmsr
0003C9AD 0F30 wrmsr
0003CCC8 0F30 wrmsr
0003D71A 0F30 wrmsr
0003DA0D 0F30 wrmsr
00043B49 0F30 wrmsr
00044FB4 0F30 wrmsr

 

Unfortunately I can't test this (don't have a system that needs it), so if someone wants...

AppleIntelCPUPowerManagement.kext.zip

[rcork]

Here .. AppleIntelCPUPowerManagement.kext.zip

 

Try this.....

AppleIntelCPUPowerManagement.kext-PATCHED.zip

 

I found 10 locations that needed to be patched

 

0000000000008f0e movl $0x000000e2,%ecx
0000000000008f13 wrmsr

000000000000979d movl $0x000000e2,%ecx
00000000000097a2 movq %rsi,%rdx
00000000000097a5 wrmsr

0000000000009828 movl $0x000000e2,%ecx
000000000000982d movq %rsi,%rdx
0000000000009830 wrmsr

0000000000009875 movl $0x000000e2,%ecx
000000000000987a movq %rsi,%rdx
000000000000987d wrmsr

00000000000099a8 movl $0x000000e2,%ecx
00000000000099ad wrmsr

0000000000009cc3 movl $0x000000e2,%ecx
0000000000009cc8 wrmsr

000000000000a715 movl $0x000000e2,%ecx
000000000000a71a wrmsr

000000000000aa08 movl $0x000000e2,%ecx
000000000000aa0d wrmsr

0000000000010b44 movl $0x000000e2,%ecx
0000000000010b49 wrmsr

0000000000011faf movl $0x000000e2,%ecx
0000000000011fb4 wrmsr

 

I only patched the 64bit code so make sure you are running in 64-bit mode, not 32-bit

AppleIntelCPUPowerManagement.kext-PATCHED.zip

Edited February 18, 2012 by rcork

[jazzyguy]

Try this.....

 

 

I found 10 locations that needed to be patched

 

0000000000008f0e movl $0x000000e2,%ecx
0000000000008f13 wrmsr

000000000000979d movl $0x000000e2,%ecx
00000000000097a2 movq %rsi,%rdx
00000000000097a5 wrmsr0000000000009828 movl $0x000000e2,%ecx

000000000000982d movq %rsi,%rdx
0000000000009830 wrmsr

0000000000009875 movl $0x000000e2,%ecx
000000000000987a movq %rsi,%rdx
000000000000987d wrmsr

00000000000099a8 movl $0x000000e2,%ecx
00000000000099ad wrmsr

0000000000009cc3 movl $0x000000e2,%ecx
0000000000009cc8 wrmsr

000000000000a715 movl $0x000000e2,%ecx
000000000000a71a wrmsr

000000000000aa08 movl $0x000000e2,%ecx
000000000000aa0d wrmsr

0000000000010b44 movl $0x000000e2,%ecx
0000000000010b49 wrmsr

0000000000011faf movl $0x000000e2,%ecx
0000000000011fb4 wrmsr

 

I'll test momentarily.

 

What are the ones where there are three rows?

 

And in case I want to do this, when you find one, how do you know what to replace it with?

[rcork]

Those just had instructions between populating ECX and calling WRMSR. When looking for which locations to patch, we need to look at all the WRMSR operations and then find those where ECX had been set to 0xe2 before the call. Make sense?

[jazzyguy]

It does work, thanks guys!

 

Rcork, I see what oldnapalms numbers are, the offset for easy finding, but then what are your numbers? I want to compare to see what the three line things look like, but I don't see what your numbers reference.

 

edit- I now see the thing with the command in the middle. But still. what are your numbers?

 

For patching, MachOView will not be enough.

Saving

and searching disassembled code does not work. But you can use otool:

otool -tV -arch x86_64 AICPUPM.kext/Contents/MacOS/AICPUPM > tmp.asm

and then search through tmp.asm in text editor.

One note: addresses here are, hm ... do not know how to say it simply and still be correct ... maybe it's easiest to compare them with MachOView offsets - so just add some constant to them (in above example for 10.7.3 it is hex 0x1000) to get positions of each instruction in the file.

 

And then last question: how do I actually patch? I see how to save to tmp.asm, but how does that get back inside the kext then?

 

Also, what is he talking about with the 0x1000? Sorry for the easy questions, but I appreciate it, now I can just about do this on my own if the need ever arises.