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:
_wrmsr_carefully:
+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!
Notes:
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.
Update-4
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.
Update
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?
Update-2
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 😉
Update-3
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.
Pike's Universum 
great findings! , am i wrong to assume that it’d have the same effect as the flAked old speedstep patch ?
We first need someone to confirm that it works the way I think that it works, but yeah the idea is basically the same – prevent writes to MSR 0xE2.
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:
269237,269252c269237,269250
< 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.]….
404425c404425
062bc80: 0000 0000 0200 0000 0000 0000 0000 0000 …………….
404428c404428
062bcb0: 0000 0000 0c00 0000 0000 0000 0000 0000 …………….
404431c404431
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?
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!
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…
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
“`
or
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_kernelPike, 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.
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.
I’ll write a patch to null out 0x64c (and test) and check bit 31 MSR_TURBO_ACTIVATION_RATIO from AICPUPMI.
I will have a look at both those tomorrow…
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…
MSR_TURBO_ACTIVATION_RATIO is Zero.
Here is the complete output:
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 😉
re: cstates. Yes, I think it is because of Clover config. I don’t think I have them enabled yet in my current config.plist.
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
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.
Pike – Question – Does CodeRush’s PMPatch address this issue or just part of it?
As far as I know it “only” addresses one specific locked MSR (0xE2) but I am sure that he can add one whenever it is required.
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
10.9
CLOVER 2305
GTX 560TI
Pingback: Mavericks/Haswell Kernel Patch for Early Reboot | racerrehabman
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.
Hey. Don’t get me wrong. You deserve credit for your hard work, I just pushed you a little 😉
I was finally able to construct a 5-byte opcode for cmpw 0x00e2,%ecx. Details in an update at the end of the article on my blog. Thought you might be interested…
Sure thing. I like to see what it is that people come up with. Great job!
pikeralpha,
How does one determine if MSR is locked or not (some quick way to determine if 0xE2 is set)?
Never mind, your AICPMI.kext does it and my bit 15 of 0xE2 is set (602 chipset). 😦
Could this not be patched in the boot loader rather than hacking the BIOS?
I’m pretty sure that the locking done by the BIOS is a one way street. If it was easy to simply unlock it with software it wouldn’t be much of a lock, and it would have already been implemented in all hackintosh boot loaders.
Yes indeed. The MSR is read only after it is set so it cannot be changed by bootloaders.
So really using the term “locked MSR” is not quite accurate. This register is really a write-once MSR.
No. The lock bit (15) is set by the BIOS and then it is locked and from that moment on it is read-only so the term “locked MSR” is correct.
Thanks for the clarification (locked once you set bit15). Good information to have… Do you have a link to a whitepaper from Intel on the MSRs, or is this NDA material?
No NDA material, not anymore at least. And I am sorry, but I don’t have a link at the moment, sitting next to a vending machine for coffee with dad (grandma is being wasgoed at the moment) with my iPad.
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
You have a different problem then. Probably related to your configuration of SSDT/smbios selections.
And you really didn’t provide any details…
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 –
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.
iMac is not a very good example at all. The iMac is plugged into AC power, unlike a laptop, which must run on power provided by a finite source (battery).
Here’s the pstates on my real MacBookPro6,2:
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.
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
restart-action
cpu-p-state
0
SMC_CPU_Control_Loop
…
PLimitDict
MacBook14,2
0
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.
Pike… here is the startup AICPUPM output from my MacBookAir6,2:
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.
it seems that Clover Dev are ready your post 😉
https://sourceforge.net/p/cloverefiboot/code/2336/
Just what I expected. This is becoming another RTC-like patch, where people forget to credit someone.
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.
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 !
Here are some precision in my test 😉
GENERATED P/C STATE –
PLUGINTYPE=1 –
CpuPm and CPu0Ist dropped –
NO SLEEP
XCPM REGISTERED
ENTER XCPM Mode
ERRORS
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
GENERATED P STATE –
PLUGINTYPE=1 –
CpuPm dropped –
SLEEP WORKING
XCPM REGISTERED
DOES NOT ENTER XCPM Mode
ERRORS
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 –
NO SLEEP
NO ERROR
XCPM REGISTERED
ENTER XCPM Mode
Pingback: Checks for two unused processor models found… – Pike's Universum