Jump to content

Speedstep after Upgrade to Lion


rhysox
 Share

1 post in this topic

Recommended Posts

Hi All,

 

I've recently upgraded from 10.6.8 to 10.7.3 on my hackintosh. I used to run speedstep with a patched AICPM kext (using speedstepper) which gave me two P-states, 16 and 45. Which is exactly the same as what I have in Windows. When I first rebooted after the Lion upgrade it immediately kernel panicked as I assume that the patched AICPM was replaced by a stock one from Lion. I had to put NullCPUPowerManagement in place to get me to this stage.

 

Hardware specification:

 

Intel i7-2600k @ 4500MHz (in Turbo) with 1.375 vCore

ASUS P8Z68-V PRO Revision B3

Corsair Vengeance 4x4GB DDR3

Dual ATI 5770 HD 1024MB

 

Note: I'm not using a DSDT, when I tried it caused a hang with '[ PCI Configuration Begin ]', and I never used a DSDT with 10.6 either.

 

With NullCPUPowerManagement I get the following-

 

 

Apr 29 12:05:29 soundwave kernel[0]: MSRDumper CoreMulti(16)
Apr 29 12:05:29 soundwave kernel[0]: MSRDumper PStatesReached: 16 34
Apr 29 12:05:29 soundwave kernel[0]: MSRDumper CoreMulti(34)
Apr 29 12:05:29 soundwave kernel[0]: MSRDumper PStatesReached: 16 34 

 

If I try and patch AICPM.kext (com.apple.driver.AppleIntelCPUPowerManagement (167.3.0)) using the two methods that I've found within this forum I get the following results...

 

AICPMPatch.pl:

 

 

soundwave:Downloads rdo$ sudo perl AICPMPatch.pl /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement --patch

/System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement

arch: x86_64

file is already patched or untested version


arch: i386

file is already patched or untested version

 

Speedstepper Beta (10.7.2):

 

 

soundwave:Downloads rdo$ sudo ./speed_stepper_lion_1072 /System/Library/Extensions/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement
SpeedStepper v1.2 - (c) flAked 2011
for AICPUPM v167.0.0 - Lion 10.7.2

Searching for wrmsr #0: a51a
-> ERR: bytes not found!

Searching for wrmsr #1: a5e2
-> ERR: bytes not found!

Searching for wrmsr #2: a660
-> ERR: bytes not found!

Searching for wrmsr #3: a6a9
-> ERR: bytes not found!

Searching for wrmsr #4: af64
-> ERR: bytes not found!

Searching for wrmsr #5: b016
-> ERR: bytes not found!

Searching for wrmsr #6: b0d4
-> ERR: bytes not found!

Searching for wrmsr #7: b6f1
-> ERR: bytes not found!

Searching for wrmsr #8: 11abe
-> ERR: bytes not found!

Searching for wrmsr #9: 11b7c
-> ERR: bytes not found!

Sorry, didn't find all wrmsr, your kernel might crash.

 

My org.chameleon.Boot.plist:

 

soundwave:Extra rdo$ cat org.chameleon.Boot.plist
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC
"-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0">
<dict>
<key>GenerateCStates</key>
<string>Yes</string>
<key>GeneratePStates</key>
<string>Yes</string>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
	<string>-v npci=0x2000 PCIRootUID=1</string>
<key>GraphicsEnabler</key>
<string>Yes</string>
<key>Timeout</key>
<string>2</string>
<key>Legacy Logo</key>
<string>Yes</string>
<key>EthernetBuiltIn</key>
<string>Yes</string>
</dict>
</plist>

 

My smbios.plist:

 


soundwave:Extra rdo$ cat smbios.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>SMfamily</key>
<string>MacBookPro</string>
<key>SMproductname</key>
<string>MacBookPro8,3</string>
<key>SMboardproduct</key>
<string>Mac-942B59F58194171B</string>
<key>SMserial</key>
<string>C02FT7U2DHJP</string>
<key>SMbiosversion</key>
<string>######.tonymacx86.com</string>
</dict>
</plist>

 

I'd really like to get my proper P-states back and not have to use NullCPUPowerManagement.kext, can someone please point me in the right direction? Should I try and get it to work with native speedstep? I do also run Windows so not sure whether BIOS hacking is the way forward.

 

Many thanks for your support,

Rhys

Link to comment
Share on other sites

 Share

×
×
  • Create New...