Major breakthrough for power management

Someone asked me why he only got a few P-States with his Haswell setup (GA-Z87MX-D3H motherboard) when logIPGStyle – Intel Power Gadget style logging – is set to false in AppleIntelCPUPowerManagementInfo.kext/C*/Info.plist The expected output is something like this:

AICPUPMI: CPU P-States [ 8 17 34 35 36 37 38 ]

Three P-States (8, 17 and 34) plus the four turbo states (35-38). I know. I used to say that this is pretty normal, but now I know better. Yes indeed. I finally figured it out, and as a result his setup now gives him a lot more P-States:

AICPUPMI: CPU P-States [ 8 17 (20) 21 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 ]

Yes. This is with logIGPStyle set to false. The trick was to change two settings in the Gigabyte UEFI BIOS
With the Auto settings giving us this:

MSR_PP0_CURRENT_CONFIG…..(0x601) : 0x1F40
MSR_PKG_POWER_LIMIT……..(0x610) : 0xFFD00000EA82
MSR_PP0_POWER_LIMIT……..(0x638) : 0xFFD0
MSR_PP1_POWER_LIMIT……..(0x640) : 0xFFD0

Note: MSR_PP1_POWER_LIMIT is for the IGPU only!

Then we changed the values from Auto to:
And this is the result:

MSR_PP0_CURRENT_CONFIG…..(0x601) : 0x2F8 (760 >> 3) is 95 Amp
MSR_PP0_POWER_LIMIT……..(0x638) : 0x82A0 (672 >> 3) is 84 Watt
MSR_PP1_POWER_LIMIT……..(0x640) : 0x82A0 (672 >> 3) is 84 Watt

The value 3 above is taken from (MSR_RAPL_POWER_UNIT & 0xf) and that equals to power units of 1/8 Watt – hence the right shift to get the proper value.

We also changed some other settings, this to be certain that XCPM is controlling power management, and not the BIOS:

Let me know if this works for your setup as well.



We already knew that MSR_PMG_CST_CONFIG_CONTROL is re-initialised by XCPM, the mach_kernel, but I also found out that the IA32_ENERGY_PERF_BIAS (0x1B0) MSR is set by data that is taken from the resource plist (think Mac-F60DEB81FF30ACF6.plist et all).


Ok. This proves that I was right when I said that having more P-States isn’t necessarily better. In fact. It now results in a (somewhat) slower PC, because the Geekbench v3.1.2 (32-bit mode) score is 3624/11298 without the changes in the UEFI BIOS (auto versus 85 Watts and 95 Amps) and 3613/9501 with the changes.

MacBook Pro data:

MSR_RAPL_POWER_UNIT……..(0x606) : 0xA0E03
MSR_PP0_CURRENT_CONFIG…..(0x601) : 0x1814149480000380
MSR_PKG_POWER_LIMIT……..(0x610) : 0x8000815E00DC8118
MSR_PP0_POWER_LIMIT……..(0x638) : 0x0

MacBook Air data:

MSR_RAPL_POWER_UNIT……..(0x606) : 0xA0E03
MSR_PKG_POWER_LIMIT……..(0x610) : 0x4283E800DD8320
MSR_PP0_CURRENT_CONFIG…..(0x601) : 0x4010141400000100
MSR_PP0_POWER_LIMIT……..(0x638) : 0x0


Someone over at Tony’s place with a Gigabyte GA-Z87X-UD5H board (F9 bios) ran into another PM related issue – using ‘Auto’ as core ratio, instead of setting it manually to anything but 35 made PM fail for him.

I checked the MSR log of AppleIntelCPUPowerManagementInfo.kext from another user with a similar issue and found this:

MSR_PLATFORM_INFO……….(0xCE) : 0x80838F301002300

Nothing wrong here. Perfectly fine for his i7-4770K. The detected minimum and maximum core ratios are also fine.

CPU Low Frequency Mode………….: 800 MHz
CPU Maximum non-Turbo Frequency….: 3500 MHz
CPU Maximum Turbo Frequency……..: 3900 MHz

But then I spotted this:

MSR_TURBO_RATIO_LIMIT……(0x1AD) : 0x27272727

What is interesting here is that all core turbo ratios are set to 27 (3.9GHz) and thus a single turbo request will result in the top frequency of the processor. Completely ignoring the fact that the first turbo frequency must be set to the core ratio + 1. In this case 36. Otherwise we ran into issue ages ago already. Remember?

I have asked the person to set the first turbo ratio back to 36 and the core ratio to 35 (or auto) to see what this does. I’ll keep you posted if I have anything new to report.

Thanks to Toleda for the heads up😉


Both MSR_PP0_POWER_LIMIT and MSR_PP1_POWER_LIMIT are set to zero (0) on Apple hardware, and using two lines in the boot loader:


Didn’t change anything. Which is positive.

31 thoughts on “Major breakthrough for power management

  1. I got a similar problem, but is about IGPU only. I have AMD/ATI radeon 280x as primary and IGPU enable as secondary to use airplay following toleda guide (ig-plataformid = 04120004 in clover, because I dont use any display connected to IGPU) and all system work fine BUT IGPU power manager:

    AICPUPMI: CPU P-States [ (8) 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 ] iGPU P-States [ 8 (24) ]

    Intel Power Gadgets shows a strait line on GT: 1.2 GHz and i confirm with toleda that IGPU is running at full power all the time, now lowering to 0.2ghz as expected.

    your ssdtgen (great, by the way) dont have any info about IGPU, so I dont know where the error starts. console doesnt show any valid information for me.

    XCPM: registered
    IOPPF: XCPM mode

    I dont have any error related to IGPU power management, except the [AGPM Controller] unknownPlatform error with is related to the radeon, not IGPU (because imac 14.2 dont have radeon video cards…)

  2. piker,
    board id = Mac-27ADBB7B4CEE8E61
    I didnt try to remove Radeon yet, because my board didnt have mini-DP onboard, so I need to remove videocard and cables, it is not easy on my deck now….

    I didnt change anything on AppleGraphicsPowerManagement, but i will looking for as you suggest.

    yes, logIGPStyle is true. sorry to comment that IGPU issue, but as you comment that sometimes it not getting all p-states and I have a similar problem….

    also, i forgot, ACPI devices are: IGPU and PEGP (IOACPIPlane:/_SB/PCI0@0/P0P2@10000/PEGP@0) there is no GFX0 on ioreg.

  3. Hi Pike,

    It’s Mark. With my xeon e5-2690 v2 I have the following values:

    MSR_PP0_CURRENT_CONFIG…..(0x601) : 0x14149480000520
    MSR_PP0_POWER_LIMIT……..(0x638) : 0x80000000 / only lock-bit set

    do you have more information about the 0x601 register? It’s not listed in Intel® 64 and IA-32 Architectures Software Developer’s Manual.

    I don’t have any possibilities to do the BIOS changes. I don’t see these options.

  4. It is interesting that the GB score is lower with fewer P-States, esp since Turbo states seem all to be reached. Why is it so?

    • Your Geekbench score is lower with fewer p-states? Here that is the other way around. But wait. What is logIGPStyle set to in AppleIntelCPUPowerManagementInfo.kext/C*/Info.plist

    • Arrg sorry, I misspelled, I meant _higher_ as described in your entry. Just wonder why this is actually the case.

      • Ah ok. You got me a little worried. Thanks for clearing this up.

        About the lower Geekbench score. I’m not quite certain as to why this is happening. I have some ideas, but I want to verify it, before I blame something that may not be the root cause.

  5. Great work Pikeralpha,

    I have an ASUS P8Z77-Pro with i7 3770K. I was able to implement this method with a patched XNU Kernel and I now have a stable system with MacPro 6,1 SMBIOS. An auto generated SSDT in clover works great, so there seems to be no need for the run the SSDT script on the ASUS motherboard. I also disabled the C3/C6/C7 Reporting in the BIOS to allow only the kernel to control P-States as you advised. I have also OverClocked the system to 4.8GHz and I get all 33 P-States from 1.6 to 4.8GHz.

    Many thanks

      • Hi Piker, I have email you my tables. Even though the system seems stable, I have ever in XCPM mope which are causing intermittent sleep problem.

        01/06/2014 14:57:41.000 kernel[0]: XCPM: registered
        01/06/2014 14:57:41.000 kernel[0]: IOPPF: XCPM mode
        01/06/2014 14:57:41.000 kernel[0]: XCPM: P-state table mismatch (error:0x11)
        01/06/2014 14:57:41.000 kernel[0]: X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11

  6. Hi Piker,

    Thanks for the help. The only error that remains is the one below. Its not causing and major issues at the moment as so that auto sleep, auto wake and auto Time Machine backups are working well.
    kernel[0]: X86PlatformShim::start – Failed to send stepper

    I had to disable additional UEFI BIOS features as shown in the link below to allow the XCPM kernel to do all the power management.

    I used your SSDT script like this: ./ -turbo 4800 -t 77 -w 2 -x 1

    Thanks again for your hard work.

  7. I found only one problem with making these bio changes. I am unable to wake the system by pressing a key on the keyboard, or moving my mouse. I have to actually press the power button, then the system wakes. Does anyone suggest a resolution for this ?

  8. hi pike greate blog man.. I have sabertooth x79 3930k not overclocked but gets higher temps in mavericks like 45c could you help me fix that pls .. in win 8.1 its much cooler like 35c.. ive followed some guides and used their patched pm kext and generated my own ssdt but maybe i didnt wrong and therefor the higher temps i really would like to mix that problem mate.. i have latest asus bios btw.. i hope you could help me thanks

    • Sorry. I either did not get a notification about the port you made here, or I forgot to reply to you. Anyway. This problem should be fairly easy to fix. Looking at your frequency table, which is way off what it should be… and this is a problem in Clover rather than anything else. I helped slice with this, but I don’t know which configuration option you have to use. Please ask in the general clover thread over at insanelymac or ask the Clover developer over at projectosx

  9. Hi Pike, let me first thank you for all of your hard work in the mackintosh community. Your blogs are great and give me the opportunity to experiment with lots of os x features, like power management.
    I’m using a GA Z77-D3H with a i5-3570 (non-k) and Ozmosis1479. Configured as iMac13,1. Ivy bridge isn’t meant to be used with xcpm as far as I know. However, I like to experiment and use xcpm anyway, but get stuck with the following message:
    01/12/14 13:06:22,000 kernel[0]: X86PlatformShim::sendPStates – Success!
    01/12/14 13:06:22,000 kernel[0]: X86PlatformShim::sendPStates – Success!
    01/12/14 13:06:22,000 kernel[0]: X86PlatformShim::sendPStates – Success!
    01/12/14 13:06:22,000 kernel[0]: X86PlatformShim::sendPStates – Success!
    01/12/14 13:06:22,000 kernel[0]: X86PlatformShim::start – Failed to send stepper

    I manually defined the power and current limit in bios, but console shows me:
    01/12/14 13:06:22,000 kernel[0]: AICPUPMI: MSR_PP0_CURRENT_CONFIG…..(0x601) : 0x1814149400000380
    01/12/14 13:06:22,000 kernel[0]: AICPUPMI: MSR_PP0_POWER_LIMIT……..(0x638) : 0x8268
    I can find no reason why the current isn’t ‘translated’ the correct way like in your guide.
    I only have turbo and enhanced c1e enabled in bios.
    SSDT was created with -w 2 -x 1 -turbo 4200.
    I get the full list of P-states: 01/12/14 13:08:08,000 kernel[0]: AICPUPMI: CPU P-States [ (16) 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 ]

    Question 1: what did I miss/do wrong?? Is it just that xcpm and Ivy are never going to work together?

    Question 2: how is it possible that I can overlock with a locked CPU? Normally max turbo is 3800 with this CPU, but I can set it at 4200?! I also noticed that xcpm costed me some performance. GB3 64 bits dropped from 12000 to 11400, but now with those higher turbo limits It’s 12500. That would suggest that using AICPM would get me 13000+. Is it normally possible to set non-k CPU’s to higher turbo states in bios and are there any downsides to doing that?

    Hopefully you can get me a step further.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s