Experimental bin patch for Maverick

Some people are experiencing a reboot with Mavericks, because XCPM (read: mach_kernel power management) writes to a locked register (bit 15 of MSR 0xE2 is set) and that is why I looked at the disassembled code of the mach_kernel (the XCPM source code is still not released by Apple) and I found a routine that we might have to change a little. Here it is:

    +0  ffffff80002d5ad0  89f9                      movl        %edi,                         %ecx
    +2  ffffff80002d5ad2  89f0                      movl        %esi,                         %eax
    +4  ffffff80002d5ad4  48c1ee20                  shrq        $0x20,                        %rsi
    +8  ffffff80002d5ad8  89f2                      movl        %esi,                         %edx
   +10  ffffff80002d5ada  0f30                      wrmsr
   +12  ffffff80002d5adc  31c0                      xorl        %eax,                         %eax
   +14  ffffff80002d5ade  c3                        ret
   +15  ffffff80002d5adf  b801000000                movl        $0x1,                         %eax
   +20  ffffff80002d5ae4  c3                        ret

This routine might be used by calls to wrmsr and thus I like to propose a small change to see if I am right. Or not of course. Anyway. Change the 0f30 into 9090 and see if that stops it from rebooting.

If this change stops it from rebooting, then we can come up with something that filters out MSR 0xE2 (_xcpm_core_scope_msrs) and do what we want it to do. Otherwise we may try to change the value of _xcpm_core_scope_msrs (0xE2) into something like 0xC3 (for example). For this you have to search for:

E2 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 07 00 00 1E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

E2 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 05 00 00 1E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

E2 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 08 00 00 7E 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Then you change the value E2 (in red) into C3. Let me know if this works or not. Thanks!


I did not mention the assembler code that uses this data, simply because if I have to tell people that then they probably don’t even know what to do with it, but trust me… I certainly know what is calling it.


The values in blue are stored into the MSR (0xE2) but only one is used and the value depends on the SKU (processor model). We know this because the output of AppleIntelCPUPowerManagementInfo.kext of a MacBookAir6,2 shows us that it is set to 0x7E000008 and my desktop processor uses the second block, which I know because I changed the value from 0x1E000005 to 0x1E000007 and that now shows up in the output of AppleIntelCPUPowerManagementInfo.kext In other words. We should only have to change one block. Not all three.


I did some more testing and have tried setting bit-1 of MSR 0x1AA (MSR_MISC_PWR_MGMT) with RevoBoot, but then even my Gigabyte desktop board reboots. Pretty interesting.

Also. _xcpm_cpu_model_get is called from _xcpm_perf_bias_set (jmpq 0xffffff80002f9ba0) and thus you can eliminate the initialisation altogether by nop’ing it out (falling back to AppleIntelCPUPowerManagement.kext for supported processors) but I would much rather have a patch that only skips the MSR that triggers the reboot. In short: Is this bit (1) the problematic one?


Cool. This is no longer an issue. RehabMan confirmed that the first patch will not work, but my second proposal does – he worked out a patch so now people with a locked (UEFI) BIOS can boot Mavericks… with the vanilla stock mach_kernel. All you need now is a boot loader that can patch the kernel, or patch the mach_kernel manually.

Thanks to RehabMan for all testing and coming up with a patch, even if I would have done it a little differently – see comments (there are many roads to Rome, but as long as one brings you to Rome… then I am fine with it😉


Just for the record; You only need to patch the mach_kernel when it reboots due to a locked MSR (0xE2) and if PMPatch (by CodeRush) isn’t working for you or when you don’t want to/can use it, but all other people should check this out.

66 thoughts on “Experimental bin patch for Maverick

  1. I just tried this and I can verify that eliminating all the wrmsrs from this function does, indeed, avoid a reboot. This is the patch I used:

    perl -pi -e ‘s|\x0f\x30(\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce\x75)|\x90\x90${1}|g’ mach_kernel

    Before I came across the solution where I simply built the kernel without xcpm (because Apple forgot to include the source for it… on purpose probably) to work around this problem, I attempted a patch to eliminate only the wrmsr with 0xe2. I don’t know why I didn’t try to eliminate all of the wrmsr to any register, but I was just only focused on 0xe2, I guess.

    That patch is these two perl scripts:
    # patching code you identified above
    perl -pi -e ‘s|(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce\x75)\x99(\x5d\xc3\x90{3})\x90{4}|\x85\xc9\x74\x07${1}\x95${2}|g’ mach_kernel

    # patching _xcpm_core_scope_msrs
    perl -pi -e ‘s|\xe2(\x00{3}\x02\x00{12}\x04\x00{6}\x07\x00{2}\x1e\x00{20})\xe2(\x00{3}\x0c\x00{12}\x04\x00{6}\x05\x00{2}\x1e\x00{20})\xe2(\x00{3}\x10\x00{12}\x04\x00{6}\x08\x00{2}\x7e\x00{20})|\x00${1}\x00${2}\x00${3}|g’ mach_kernel

    The easiest way to see what the difference is is to diff the hex output from the original kernel and the patched one created by the above patches (first patch, for data differences), and diff the disassembly output (otool -tV) for the code changes (second patch). For the first patch, there is some extra (7) nops at the end of this function, so there is room to add code to test for a non-zero msr register in the data and jump around the wrmsr in that case. The second patch changes all the e2 instances in _xcpm_core_scope_msrs to zero.

    otool diffs:
    < ffffff80002f9bfc wrmsr
    < ffffff80002f9bfe movl 0xffffffffffffffd8(%rdi), %ecx
    < ffffff80002f9c01 rdmsr
    < ffffff80002f9c03 movl %eax, %eax
    < ffffff80002f9c05 shlq $0x20, %rdx
    < ffffff80002f9c09 orq %rax, %rdx
    < ffffff80002f9c0c movq %rdx, (%rdi)
    < ffffff80002f9c0f addq $0x30, %rdi
    < ffffff80002f9c13 decl %esi
    < ffffff80002f9c15 jne 0xffffff80002f9bb0
    < ffffff80002f9c17 popq %rbp
    < ffffff80002f9c18 ret
    < ffffff80002f9c19 nop
    < ffffff80002f9c1a nop
    < ffffff80002f9c1b nop
    ffffff80002f9bfc testl %ecx, %ecx
    > ffffff80002f9bfe je 0xffffff80002f9c07
    > ffffff80002f9c00 wrmsr
    > ffffff80002f9c02 movl 0xffffffffffffffd8(%rdi), %ecx
    > ffffff80002f9c05 rdmsr
    > ffffff80002f9c07 movl %eax, %eax
    > ffffff80002f9c09 shlq $0x20, %rdx
    > ffffff80002f9c0d orq %rax, %rdx
    > ffffff80002f9c10 movq %rdx, (%rdi)
    > ffffff80002f9c13 addq $0x30, %rdi
    > ffffff80002f9c17 decl %esi
    > ffffff80002f9c19 jne 0xffffff80002f9bb0
    > ffffff80002f9c1b popq %rbp
    > ffffff80002f9c1c ret

    Note: Maybe the problem was that I jumped around the rdmsr as well?

    xxd diffs:
    < 00f9bf0: 49c1 e920 89d0 8b4f d84c 89ca 0f30 8b4f I.. …O.L…0.O
    < 00f9c00: d80f 3289 c048 c1e2 2048 09c2 4889 1748 ..2..H.. H..H..H
    00f9bf0: 49c1 e920 89d0 8b4f d84c 89ca 85c9 7407 I.. …O.L….t.
    > 00f9c00: 0f30 8b4f d80f 3289 c048 c1e2 2048 09c2 .0.O..2..H.. H..
    > 00f9c10: 4889 1748 83c7 30ff ce75 955d c390 9090 H..H..0..u.]….
    062bc80: 0000 0000 0200 0000 0000 0000 0000 0000 …………….
    062bcb0: 0000 0000 0c00 0000 0000 0000 0000 0000 …………….
    062bce0: 0000 0000 1000 0000 0000 0000 0000 0000 …………….

    My thought now is that there are locked MSRs causing reboot other than 0xE2. I could certainly try to eliminate them one by one to see the responsible registers. Knowing what you know about these MSRs can you think of a likely problematic one? Here is a list of the other registers potentially written by this function:

    from _xcpm_pkg_scope_msrs:
    0xa001, 0xfc01, 0xaa01, 0x2006, 0x4c06, 0x3a06, 0x4206

    from _xcpm_SMT_scope_msrs
    0x2e00, 0xa001, 0xb001 (twice), 0x0906

    The first patch can be used in conjunction with additional patches for the _xcpm_pkg_scope_msrs and _xcpm_SMT_scope_msrs tables to eliminate any wrmsr the system finds objectionable.

    Any ideas on which MSRs I should focus on first?

  2. Oh… I just noticed something else… You patched the wrmsr_carefully… I saw that, but couldn’t find anything that called it. My patch above did not patch that function, so given that I patched a different chunk of code (and it worked), I doubt patching the _wrmsr_carefully will have any affect.

    I don’t have time to test that theory right now, so that will have to wait for later. I guess you can now checkout the spot that my patch *did* patch and see what you think of that!

  3. FYI: Patch for just skipping the wrmsr (instead of rdmsr as well):

    perl -pi -e ‘s|(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce\x75)\x99(\x5d\xc3\x90{3})\x90{4}|\x85\xc9\x74\x02${1}\x95${2}|g’ mach_kernel

    I think at one point, when skipping over the wrmsr didn’t work for me, I changed it to also skip over the rdmsr just to see what would happen. It didn’t help. It has to be one of the other msrs being written to in addition to the already known 0xE2…

    Next update when/if I figure it out…

  4. BTW, I see that wordpress is not dealing well with the long perl patch lines. Thanks wordpress… you suck.

    This post is an attempt to use some code blocks:
    perl -pi -e ‘s|(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce\x75)\x99(\x5d\xc3\x90{3})\x90{4}|\x85\xc9\x74\x02${1}\x95${2}|g’ mach_kernel


    perl -pi -e 's|(\x0f\x30\x8b\x4f\xd8\x0f\x32\x89\xc0\x48\xc1\xe2\x20\x48\x09\xc2\x48\x89\x17\x48\x83\xc7\x30\xff\xce\x75)\x99(\x5d\xc3\x90{3})\x90{4}|\x85\xc9\x74\x02${1}\x95${2}|g' mach_kernel
  5. Pike, if you got the full text of the patches, feel free to edit to use the code block (second form). If I had realized it was going to truncate, I would have used the block…

    Otherwise, I can post again with the complete code blocks for the perl patches.

  6. Note: Forgot to byte-reverse some stuff (I’m looking at xxd dump):

    So where I have:
    from _xcpm_pkg_scope_msrs:
    0xa001, 0xfc01, 0xaa01, 0×2006, 0x4c06, 0x3a06, 0×4206

    from _xcpm_SMT_scope_msrs
    0x2e00, 0xa001, 0xb001 (twice), 0×0906

    We are actually talking about them byte-reversed, so the MSR register numbers are:
    from _xcpm_pkg_scope_msrs:
    0x01a0, 0x01fc, 0x01aa, 0×0620, 0x064c, 0x063a, 0×0642

    from _xcpm_SMT_scope_msrs
    0x2e, 0x01a0, 0x01b0 (twice), 0x0609

    Sorry for the multiple posts. Hopefully you get the idea…

    • No worries about the byte-reversing. And I think to have narrowed down the problem to MSR 0x64C so please check the output of AppleIntelCPUPowerManagementInfo.kext Look for: MSR_TURBO_ACTIVATION_RATIO and check if bit 31 is set.

      • Make sure to add the output of AICPUPMI so that I can look at it – bit 1 of MSR 0x1AA might also be of interest to us, because setting it in RevoBoot triggers a reboot on my desktop CPU.

      • Update…

        BTW, I see I’ve missed (!!) some relative conditional jumps that need adjustment. And I probably do have to skip the rdmsr as reading MSR 0 is probably not a good idea…


        Here is the complete output:

        MSR_CORE_THREAD_COUNT......(0x35)  : 0x40008
        MSR_PLATFORM_INFO..........(0xCE)  : 0x80838F3011800
        MSR_PMG_CST_CONFIG_CONTROL.(0xE2)  : 0x1E008405
        MSR_PMG_IO_CAPTURE_BASE....(0xE4)  : 0x21814
        IA32_MPERF.................(0xE7)  : 0x6873749D78
        IA32_APERF.................(0xE8)  : 0x32461420E7
        MSR_IA32_PERF_STATUS.......(0x198) : 0x21F400002000
        MSR_IA32_PERF_CONTROL......(0x199) : 0x2000
        IA32_CLOCK_MODULATION......(0x19A) : 0x0
        IA32_THERM_STATUS..........(0x19C) : 0x882A0000
        IA32_MISC_ENABLES..........(0x1A0) : 0x850089
        MSR_MISC_PWR_MGMT..........(0x1AA) : 0x400001
        MSR_TURBO_RATIO_LIMIT......(0x1AD) : 0x20202122
        IA32_ENERGY_PERF_BIAS......(0x1B0) : 0x8
        MSR_POWER_CTL..............(0x1FC) : 0x4005F
        MSR_RAPL_POWER_UNIT........(0x606) : 0xA0E03
        MSR_PKG_POWER_LIMIT........(0x610) : 0x804281D600DC8178
        MSR_PKG_ENERGY_STATUS......(0x611) : 0x2A6071F
        MSR_PP0_CURRENT_CONFIG.....(0x601) : 0x101414000002A0
        MSR_PP0_POWER_LIMIT........(0x638) : 0x0
        MSR_PP0_ENERGY_STATUS......(0x639) : 0x128EEA2
        MSR_PP0_POLICY.............(0x63a) : 0x0
        MSR_CONFIG_TDP_NOMINAL.....(0x648) : 0x18
        MSR_CONFIG_TDP_LEVEL1......(0x649) : 0x0
        MSR_CONFIG_TDP_LEVEL2......(0x64a) : 0x0
        MSR_CONFIG_TDP_CONTROL.....(0x64b) : 0x80000000
        MSR_TURBO_ACTIVATION_RATIO.(0x64c) : 0x0
        MSR_PKG_C3_RESIDENCY.......(0x3f8) : 0x0
        MSR_PKG_C6_RESIDENCY.......(0x3f9) : 0x0
        MSR_PKG_C7_RESIDENCY.......(0x3fa) : 0x0
        AICPUPMI: Low Frequency Mode : 800 MHz
        AICPUPMI: Clock Speed        : 2400 MHz
        AICPUPMI: Max Turbo Frequency: 3400 MHz
        AICPUPMI: IGPU Current Freq..:  200 MHz
        AICPUPMI: IGPU Max Frequency.:  400 MHz
        AICPUPMI: IGPU Max Turbo Freq: 1150 MHz
      • Thanks. For your info: C-States are not working!

        Try this in a terminal window:

        sudo kextunload AppleCPUPowerManagementInfo.kext
        sudo kextload AppleCPUPowerManagementInfo.kext
        cat /var/log/system.log | grep AICPUPMI

        If that didn’t change the output… you have more work to do😉

  7. How do I get XCPM to work with Xeon E5 2689 (v1). My CPU does not even get recognized (About This Mac says Unknown) and if I use any XCPM kernel flags, computer reboots right away?

    • Not exactly on topic, but you should use the correct SMBIOS value for you CPU (0x501 if I’m not mistaken) and XCPM is not developer for older processors so I don’t know if that will ever work.

      • Thanks for your response. My understanding is that XCPM was written with intent to be used for Xeon E5 v2 in the new Mac Pro (the trash-can), else there’s no evidence that legacy power management will support it, yet (unless Apple adds it in the pending 10.9.2 Mavericks updated due out soon).

        Thus, would it not be possible to use the XCPM with E5 v1 if it’s meant to work for v2? Or is XCPM in your opinion only meant for Haswell based iMacs, Minis and MacBooks and trash-can Pro will use something else?

      • XCPM also supports the third generation Intel Core processors, and thus it isn’t written for Haswell specifically, but only Haswell processors use FrequencyVector data. Apple however did not provide data (a plist) for the new MacPro and thus we have to wait and see what it will be using.

      • Maybe all we need to do is wait for a good iMac14,2 SMBios to surface. It has Haswell and the SMBios may invoke PM calls to the kernel

  8. Oh, and how did you come up with that value of 0x501, is there a formula or a table of all values somewhere? Where would I set it though to override whatever is detected and would kernel then detect my CPU properly? Thanks.

    • 0x501 is used for Xeon processors (so far) and thus you can use this value for your SMBIOS configuration, but how you set it depends on the boot loader (I use RevoBoot and cannot help you with this).

      p.s. The value 0x501 comes from IORegistryExplorer dumps.

      • Thanks again. I’ve set the cputype to 0x501 but my CPU is still Unknown and most likely because of that I do not have native PM.
        Would you happen to know where is the CPU being detected or what affects its detection so I can work on the PM issue in AICPM?

      • The About this Mac dialog has nothing to do with power management and power management usually fails due to simple setup/configuration errors, and since your processor isn’t detected properly, that is a first sign that something isn’t done correctly/fails to work, but that is not something that we should be discussing here. My advise for you would be to search the usual fora and look for help there.

  9. you may have found one of my Major problem.
    Experiencing reboot and Kernel Panic…

    I discovered something really strange and I don’t know how I have done it.
    I may have disabled SpeedStep using CLOVER latency 0x03E9 and I also used SSDTPrGen. My multiplier was locked however consumption was correctly moving and managing… (strange I not able to do it again today, don’t know what I have done to fix that)

    Result a 4 days rock solid computer without any reboot and any KP … no more speedstep and sleep but a nice working computer
    The problem is I don’t how I have managed this because right now my SpeedStep came back and my reboot and kernel Panic with it.

    You cannot disable C-STATE in BIOS as 10.9 is able to overpass BIOS and check “deep inside somewhere”…XCPM may be problem as you have said…

    MOBO – GA Z87X-OC
    I5- 4670K
    CLOVER 2305
    GTX 560TI

  10. Pingback: Mavericks/Haswell Kernel Patch for Early Reboot | racerrehabman

  11. I have a working patch. Turns out the only problem MSR is 0xE2. I decided to explain a bit about it on my blog: http://racerrehabman.wordpress.com/2013/11/25/maverickshaswell-kernel-patch-for-early-reboot/

    If you just want to try it, apply the two perl patches from the blog post and use the resulting mach_kernel. I have not experimented how this will affect power management at this point, just booted the installer with it.

    As I mention in the article, _wrmsr_carefully is not called by the kernel and thus it does not help to patch it. The target function is a private (static) helper function called internally by mach_kernel during initialization.

    • Cool. So what you do is basically what I proposed, in case the change to _wrmsr_carefully didn’t work – change the data tables, be it with a different value, but you could have changed the data in the table – as I proposed – so that you don’t have to inject any code at all😉

      Anyway. If this works for you guys then I am cool with it. Good job!

      • Actually, no, it is not quite what you proposed. I changed the tables and the code which processes the tables (which is not _wrmsr_carefully). I haven’t tried changing just the data, as I’m not sure of a good substitute for the 0xE2. I’ll try your idea of using 0xC3 without the code changes just to see what happens. What is MSR 0xC3?

        Note that also the code is storing the value read from rdmsr (after some manipulation) back into the table, and I’m not sure what the purpose of that is yet.

        BTW, if you can think of a way to do a “cmp $e2,ecx/je-relative” in 7-bytes that would be handy.

      • Just to clarify:

        You changed 0xE2 to 0x00 in the table I mentioned and added additional code. I proposed to change the same table, but from 0xE2 to 0xC3 (I said: “for example”) in an attempt to just patch the data (table) instead of adding code that may actually break in a next update. It’s like I said: There are many ways to Rome😉

        MSR 0xC3 is a ‘General Performance Counter’ (R/W). There are eight of them (0xC1 – 0xC7). But again. This was just an example.

      • BTW, thanks Pike for making me take another look at this. Your proposal to try to eliminate all wrmsr from _wrmsr_carefully, although I read it incorrectly and thought you were proposing to patch the same code I had already been working with, caused me to try eliminating all wrmsr from the code processing the tables. When I saw that this worked, I knew my previous attempt to patch the code must have been flawed. And after disassembling my patched version and seeing that there were several conditional branches jumping into the middle of instructions (!!), I realized what I had done wrong.

        Without your prodding with this post, I might not have realized what I had done wrong for some time to come.

  12. OK I have tested the new patched Kernel using the two perl method and the new updated one perl method with the same result.

    Still have my Kernel Panic… and the computer constantly reboot. Seem that Z87X-OC does not like 10.9 and my CPU.

    Here is my test.
    For all test I’m using SSDTPrGen SSDT and modified mach_kernel

    -When I disable C-STATES in Bios.
    -Use latency 0x03E9 in clover
    I have random 10/20 minutes working computer

    -When I enable C-STATES in Bios
    -Use Latency 0x03E9 in Clover
    I have a random 30/45 minutes working computer

    -Use latency 0x03E7 in Clover
    I have a random 5/15 minutes working computer

    -Use latency 0x03E9 or 0x03E7 in clover and -Use Halt Enabler in clover
    Cannot Boot Kernel Panic
    and no Kernel Panic with Vanilla Kernel Panic (but around 30 minutes working computer)

    -When I have managed to block my Multiplier to maximum turbo
    (disabling speedstep)
    I had a 4 days working computer 24h/24 !

    thank you for your work both of you.
    So the result nothing has changed for me with Patched Kernel

      • Sorry Rehab, for the lack of details.
        MOBO – GA Z87X-OC – I5- 4670K – 10.9 – CLOVER 2305 – GTX 560TI – MAC IASL PJALM Gigabyte Z87x-OC DSDT – Using iMac14,2 – and SSDTPrGen SSDT –

  13. I may add something if this can be helpful:

    When I don’t generate any P STATE or any C/P State
    CPU is not recognized but I have sleep working

    When I use your SSDTPrGen with Patched Kernel or without
    CPU is correctly recognized but sleep does not work anymore

    When I use C/P GENERATE STATE by Clover
    CPU error and not recognized as well as sleep which does not work

    I’m currently testing NULLCPUPOWERMANAGEMENT which was not working with Vanilla Kext (had Kernel Panic) and it seems with your patched Kernel method… NULLCPU is working again… Right now I have not experienced any Kernel Panic yet …
    this is not the best way but right now it is working

    • Realize that there are several components to properly working power management that must be in sync with each other. These components in OS X have a somewhat intimate relationship and setting them up improperly will result in problems. These are the valid combinations (Haswell CPUs):

      – SSDT with plugin-type=1. Ivy era smbios.plist (eg. MacBookPro9,x, MacMini6,x). Board-id must match x86platformplugin.kext/Contents/Resources/*.plist. Non-xcpm kernel (eg. built from sources). 10.8.5 (patched) AppleIntelCPUPowerManagement.kext.
      – SSDT with no plugin-type. Sandy era smbios.plist (eg. MacBookPro8,x, MacMini5,x, etc). Non-xcpm kernel. 10.8.5 (patched) AppleIntelCPUPowerManagement.kext.
      – SSDT with plugin-type=1. Haswell era smbios.plist (eg. iMac14,2, MacBookPro11,x). xcpm kernel (patched or otherwise). AppleIntelCPUPowerManagement doesn’t matter as it won’t load.

      In all cases, you should be sure to drop OEM cstate/pstate/cpu SSDT tables when using a custom SSDT because it is bad to have duplicate/conflicting information and will usually result in KP on boot.

      So far, I have better results using ssdtPRGen.sh over Clover’s SSDT generation. Although you should always check the result of the script to be sure it is correct for your CPU specs (eg. ark.intel.com and/or output from AppleIntelCPUPowerManagementInfo.kext)

    • AppleIntelCPUPowerManagement.kext should never load on Haswell configurations (and thus NullCPUPowerManagement.kext is useless) but if it does load then you’ve done something wrong (check your configuration, again).

      • This is only true when you want to use xcpm. If you’re trying a non-xcpm config (eg. kernel built without it), then you need AppleIntelCPUPowerManagement.

        I’m not convinced yet that xcpm is a desirable config for a Haswell laptop. For example, I’m not getting pstates between idle (x8) and nominal (x24). I only get x8, x24, and turbo (up to x34) for my i7-4700mq. I’ll do some testing with my MacBookAir6,2 and perhaps a friend’s MacBookPro11,x (eventually) to see if this is normal or not.

        It could be that the bootloader/DSDT needs to inject some things to control xcpm for a better “laptop appropriate” power profile. I’m not sure what that might be…

      • There should be no need to use old school power management with Haswell processors, and I am aware of the fact that people think that getting “all” P-States is better, but I have yet to see any (Intel) documentation that this is desirable. The iMac is a perfect example, knowing that it uses a “limited” set of P-States, but there is no negative impact for the end-user. Also. XCPM is developed with Haswell and Ivy Bridge processors in mind, so I wouldn’t know a single reason why anyone would want to go back and use AppleIntelCPUPowerManagement.kext Even when XCPM isn’t fully operational, yet, or when people think that it doesn’t work. Let’s not forget, it took years before power management worked for previous generations of Intel processors, so people just need to give it a bit of time.

      • Here’s the pstates on my real MacBookPro6,2:

        AICPUPMI: CPU P-States [ 8 17 (18) 19 20 21 22 23 24 25 26 29 31 ] GPU P-States [ ]

        Couple of interesting points:
        – no states between idle (x8) and nominal (x17)
        – no gpu pstates detected

        So, it could be that we are done with CPU PM as far as xcpm. As it seems Apple is not using any states between idle and nominal by-design. If it is good enough for the 12-hour MacBookAir6,2, then it is probably good enough for hack laptops.

  14. thank you for all your advices and your time but I’m really stucked I don’t understand, why NullCPUPowermanagement is working as it should be overpassed by xcpm…
    I also don’t understand why as soon as I add SSDTPrGen SSDT sleep does not work

    I’m using SSDTPrGen SSDT with plugin-type=1. iMac 14,2. xcpm kernel (patched). I’m on 10.9.
    MOBO – GA Z87X-OC – I5- 4670K – CLOVER 2305 – GTX 560TI – MAC IASL PJALM Gigabyte Z87x-OC DSDT.

    In fact:

    @Pike and Rehab
    I can double confirm that with NullCPUPowerManagement.kext, I don’t have anymore Kernel Panic and Reboot. What does it change between with it and without it ?
    With it I noticed in HWMONITOR that Watts CPU Package Core and CPU Package Total are higher than without NUllCPUPM.kext.

    Regarding speedstep here is what I have got with SSDTprGen SSDT (iMac14,2 – SSDT Dropped of course)
    AICPUPMI: CPU P-States [ 8 ]
    AICPUPMI: CPU P-States [ 8 34 ]
    AICPUPMI: CPU P-States [ 8 34 36 ]
    AICPUPMI: CPU P-States [ 8 34 36 38 ]
    AICPUPMI: CPU P-States [ 8 ]
    AICPUPMI: CPU P-States [ 8 38 ]
    AICPUPMI: CPU P-States [ 8 34 38 ]
    AICPUPMI: CPU P-States [ 8 34 37 38 ]
    AICPUPMI: CPU P-States [ 8 ]
    AICPUPMI: CPU P-States [ 8 37 ]
    AICPUPMI: CPU P-States [ 8 37 38 ]
    AICPUPMI: CPU P-States [ 8 34 37 38 ]
    AICPUPMI: CPU P-States [ 8 ]
    AICPUPMI: CPU P-States [ 8 34 ]
    AICPUPMI: CPU P-States [ 8 34 38 ]
    AICPUPMI: CPU P-States [ 8 ]
    AICPUPMI: CPU P-States [ 8 34 ]
    AICPUPMI: CPU P-States [ 8 34 38 ]
    AICPUPMI: CPU P-States [ 8 ]
    AICPUPMI: CPU P-States [ 8 38 ]
    AICPUPMI: CPU P-States [ 8 34 38 ]
    AICPUPMI: CPU P-States [ 8 34 36 38 ]
    AICPUPMI: CPU P-States [ 8 34 36 37 38 ]
    AICPUPMI: CPU P-States [ 8 34 35 36 37 38 ]
    AICPUPMI: CPU P-States [ 8 ]
    AICPUPMI: CPU P-States [ 8 38 ]
    AICPUPMI: CPU P-States [ 8 34 38 ]

    Regarding sleep the only sleepery changed that I have done is
    I have added imac14,2 (which does not exist following imac12,2 model) in ACPI_SMC_PlatformPlugin.kext/Contents/Resources/*.plist and added these lines






    Thank you for your support and for everything

    • Here another details to add…
      I did not want to talk about it here because it is about Clover (don’t want to spam Clover in Pike work) but it may have a link that could help

      These test are done with Patched Kernel and without it

      Using Generated P/C State in Clover (all C and Halt Enabled) I have this error
      IOPPF: XCPM mode
      XCPM: P-state table mismatch (error:0x1f)
      X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x1f
      X86PlatformShim::start – Failed to send PStates
      Don’t have sleep anymore as for SSDTPrGen

      Kernel Panic without NullCPUPowerManagement (testing stability at the moment)

      Without any Generated C/P State and even droping SSDT in the same (not uning any SSDT by the way) the computer can start and work well (even Sleep is working)
      using Vanilla AppleCPUPM.kext… that’s really strange
      The only Error I have is this one
      ACPI_SMC_PlatformPlugin::start – waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
      WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x3c
      — power management may be incomplete or unsupport

      100% solid rock Fully Stable with NullCPUPowerManagement.
      5/10min reboot without it !… and I SLEEP IS WORkING ! LOL …

      That’s a real challenge to understand…

    • I haven’t tested this yet, but I wonder if iMac14,2 is an exception to xcpm. I notice they still have a plist for iMac14,2 in X86PlatformPlugin. There are no plists there matching the board-ids for the other Haswell machines (MacBookAir6,x, MacBookPro11,x).

      So, maybe they didn’t enable xcpm for iMac14,2 yet.

      I’ll test with my Haswell laptop later…

      • Just checked. Tried iMac14,2 with xcpm enabled kernel (all same as MacBookPro11,2). Everything as expected (kernel is implementing CPU PM). There is no exception for iMac14,2 although for some reason they included a plist for it in X86PlatformPlugin. Perhaps that plist serves some other purpose other than CPU PM tweaks, or they just forgot to remove it.

  15. Pike… here is the startup AICPUPM output from my MacBookAir6,2:

    MSR_CORE_THREAD_COUNT......(0x35)  : 0x20004
    MSR_PLATFORM_INFO..........(0xCE)  : 0x8083DF3011700
    MSR_PMG_CST_CONFIG_CONTROL.(0xE2)  : 0x7E000008
    MSR_PMG_IO_CAPTURE_BASE....(0xE4)  : 0x50414
    IA32_MPERF.................(0xE7)  : 0x137ABBD948
    IA32_APERF.................(0xE8)  : 0x11460D5F4B
    MSR_IA32_PERF_STATUS.......(0x198) : 0x1FC400001D00
    MSR_IA32_PERF_CONTROL......(0x199) : 0x2100
    IA32_CLOCK_MODULATION......(0x19A) : 0x0
    IA32_THERM_STATUS..........(0x19C) : 0x88340800
    IA32_MISC_ENABLES..........(0x1A0) : 0x850089
    MSR_MISC_PWR_MGMT..........(0x1AA) : 0x400001
    MSR_TURBO_RATIO_LIMIT......(0x1AD) : 0x1D1D1D21
    IA32_ENERGY_PERF_BIAS......(0x1B0) : 0xF
    MSR_POWER_CTL..............(0x1FC) : 0x4005F
    MSR_RAPL_POWER_UNIT........(0x606) : 0xA0E03
    MSR_PKG_POWER_LIMIT........(0x610) : 0x4283E800DD8320
    MSR_PKG_ENERGY_STATUS......(0x611) : 0x9DD055
    MSR_PP0_CURRENT_CONFIG.....(0x601) : 0x4010141400000100
    MSR_PP0_POWER_LIMIT........(0x638) : 0x0
    MSR_PP0_ENERGY_STATUS......(0x639) : 0x4A9C27
    MSR_PP0_POLICY.............(0x63a) : 0x0
    MSR_CONFIG_TDP_NOMINAL.....(0x648) : 0x11
    MSR_CONFIG_TDP_LEVEL1......(0x649) : 0x8005C
    MSR_CONFIG_TDP_LEVEL2......(0x64a) : 0x1700C8
    MSR_CONFIG_TDP_CONTROL.....(0x64b) : 0x0
    MSR_PKG_C3_RESIDENCY.......(0x3f8) : 0x9EC4FAA6
    MSR_PKG_C6_RESIDENCY.......(0x3f9) : 0x28041E0B9
    MSR_PKG_C7_RESIDENCY.......(0x3fa) : 0x542DF2F583
    AICPUPMI: Low Frequency Mode : 800 MHz
    AICPUPMI: Clock Speed        : 2300 MHz
    AICPUPMI: Max Turbo Frequency: 3300 MHz
    AICPUPMI: IGPU Current Freq..:  350 MHz
    AICPUPMI: IGPU Max Frequency.:  200 MHz
    AICPUPMI: IGPU Max Turbo Freq: 1100 MHz

    As a side note, I have yet to see the C6/C7_RESIDENCY fields fill in when using SSDT created with ssdtPRgen.sh on my hacks. And yet both are present here on the Air. Must be still something missing in the SSDT/cstate info.

    At any rate, I thought you might find something interesting in this AICPUPMI output from real Apple hardware.

      • Actually, they did provide credit in the source code.

        The Clover patch works only for 10.9 although I have verified (not tested) that the patch is also applicable to 10.8.5. See “Update #2” at my blog post.

      • See update #3 and #4 at my blog. I’ve crafted a patch for 10.8.5. I was looking at the wrong mach_kernel when I concluded they were the same (got confused with my many USB sticks… I really should label them more carefully).

        Note: 10.8.5 patch is not tested yet. I hope to have a chance later today to verify.

  16. Pike I have a question.

    Are you sure that SSDTPrGen is able to correctly managed HASWELL Processors because there is something strange, when I use it SLEEP is not working anymore.

    And Without any Generated C/P State and even droping SSDT OEM in Clover (not uning any SSDT by the way) the computer can start and work well and SLEEP iS WORKING !

    When I generate C/P State using Clover but Not dropping OEM PM Sleep DOES NOT WORK AGAIN … hahaha

    This one is really challenging !
    It is completely insane, I’m quite stucked and blocked !

  17. Here are some precision in my test😉

    CpuPm and CPu0Ist dropped –
    07/12/2013 05:41:11,000 kernel[0]: IOPPF: XCPM mode
    07/12/2013 05:41:11,000 kernel[0]: XCPM: P-state table mismatch (error:0x1f)
    07/12/2013 05:41:11,000 kernel[0]: X86PlatformShim::sendPStates – pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x1f
    07/12/2013 05:41:11,000 kernel[0]: X86PlatformShim::start – Failed to send PStates

    CpuPm dropped –
    07/12/2013 05:47:46,000 kernel[0]: ACPI_SMC_PlatformPlugin::start – waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
    07/12/2013 05:47:46,000 kernel[0]: WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x3c
    07/12/2013 05:47:46,000 kernel[0]: — power management may be incomplete or unsupported

    With Generated SSDT (SSDTPrGen) –
    CpuPm and Cpu0ISt Dropped –
    PLUGINTYPE=1 or 0 –

  18. Pingback: Checks for two unused processor models found… – Pike's Universum

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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