Testers needed: CPU Power Management for SB and IB Xeon(s) or i7-39xx on X79 or C60x chipset

Posted 10 January 2014 - 04:12 AM

This post was last edited on Feb. 23, 2014 at 15:00:00 EST, reason: Posted a link to MSRpatcher.dylib v007 - please read the note next to it

I'm looking for fellow users who have SB or IB Xeon(s) or i7-39xx, on X79/C60x motherboards and lack CPU Power Management, to test this hack.

This is an advanced topic and I will assume you have tried everything else and got everything else working, but are stuck with NullCPUPowerManagement.kext and two power states (min/max).

This means:

- you have Xeon-E5 v1 (SB), Xeon-E5 v2 (IB), i7-39xx or i7-49xx (the last two have the same core as Xeon counterparts, just higher clock and no MP support)

- you have cpu-type set to 0xa01 (2561) and are using MacPro6,1 in SMBIOS it appears to work better for some people as Macmini or iMac than MacPro as a platform definition,

- you have plugin-type = 0x01 set on the CPU0, to utilize X86Platform* (we might deal with ACPI_SMC_PlatformPlugin later) you are using either X86Platform or ACPI_SMC_Platform,

- when you run with AppleIntelCPUPowerManagement.kext you get "Unknown CPU: family = 0x.. , model = 0x.. , stepping = 0x.." from AICPM in kernel log at the very top before AppleACPICPU is initialized (this has nothing to do with About This Mac Unknown cpu),

- your C- and P- states are properly initialized in the registry (your SSDT is enabled and working) and are not getting any errors from X86Platform* during boot,

- you do NOT have MSR register 0xE2 bit 15 set, or you have hacked your BIOS to enable it (patched AICPM is NOT acceptable, we need a working 0xE2 MSR),

- you are running 10.9.2 build 13C32 you are running 10.9+ (normal mode, not safe mode),

Instructions:

The tool we will use to monitor things is PikeRAlpha's AppleIntelCPUPowerManagementInfo.kext, so get that from his blog, or better yet compile from github (https://github.com/P...-Alpha/RevoBoot).

So, if you are ready to test, below is a AppleInteCPUPowerManagement binary, patched to identify your Unknown CPU as SB or IB. Replace (backup first) the original one from SLE/AICPM with the appropriate one for your cpu. Make sure that permissions are correct, and if necessary touch /S/L/E to re-cache the extensions folder.

You should see your turbo modes initialized around the top of the kernel log as well as no other errors except this one: X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1.

Hopefully you won't get a KP, but if you do, record where it KPs. Once system is up, load Pike's AICPMI and take a look at the output, let your system run for a bit use it as usual, then check dmesg a fee times, it should fill with some C and P states.

Also, I'm including a patched kernel to allow for full debug output if you need it. It is very "chattery" so expect lots of text, thus boot with: mach_kernel.dbg -v -cpuid debug=0x144 msgbuf=131072

This is all preliminary work so if it does not work, well that's why we are testing...post your AICPMI output for discussion and if necessary any other kernel log related items

Please post your CPU model and Platform (MacProX,Y; MacminiX,Y; iMacX,Y) when posting your logs so we have a bit more information.

Debugging:

To get even more debugging output, boot with the following arguments:

debug=0x144 msgbuf=309212 ioppf=0xff acpi_layer=0x08 acpi_level=0x02

You will see tons of output from X86Platform* which will tell you much about your setup and whether it can parse the SSDT properly or not. Follow through with any errors and correct them, then see what happens when you load AICPMI again.

For example in my case, I only have four (index position 0-3) turbo state so the next highest non-Turbo index position would be 4:

Spoiler

Name (SPSS, Package (0x13)

{

Package (0x06)

{

0x00000E10,

0x0001C138,

0x0000000A,

0x0000000A,

0x00002400,

0x00002400

},

Package (0x06)

{

0x00000D48,

0x0001C138,

0x0000000A,

0x0000000A,

0x00002200,

0x00002200

},

Package (0x06)

{

0x00000CE4,

0x0001C138,

0x0000000A,

0x0000000A,

0x00002100,

0x00002100

},

Package (0x06)

{

0x00000C80,

0x0001C138,

0x0000000A,

0x0000000A,

0x00002000,

0x00002000

},

Package (0x06)

{

0x00000A28,

0x0001C138,

0x0000000A,

0x0000000A,

0x00001A00,

0x00001A00

},

Package (0x06)

{

0x000009C4,

0x0001AA59,

0x0000000A,

0x0000000A,

0x00001900,

0x00001900

},

....

-- If you are not sure about your C-state declarations in SSDT (or even if you are), please use the one below - regardless of whether you think you have made it right, or you let Pike's script generate it for you.

This also contains debug entries that you will see pop up in your kernel log if you have ACPI and AICPM debugging on. I don't have to tell you how to use this, do I?

Sigh, ok...CPU0 scope contains the original as is, all other CPU scopes have aliases pointing to CPU0 scope, similar to this (adjust to your config don't copy/paste):

Method (_CST, 0, NotSerialized) { Return (\_SB.CP00._CST) }

Method (ACST, 0, NotSerialized) { Return (\_SB.CP00.ACST) }

Spoiler

Name (CSTW, Package (0x04)

{

0x03,

Package (0x04)

{

ResourceTemplate ()

{

Register (FFixedHW,

0x01, // Bit Width

0x02, // Bit Offset

0x0000000000000000, // Address

0x01, // Access Size

)

},

0x01,

0x41,

0x03E8

},

Package (0x04)

{

ResourceTemplate ()

{

Register (FFixedHW,

0x01, // Bit Width

0x02, // Bit Offset

0x0000000000000010, // Address

0x03, // Access Size

)

},

0x03,

0x43,

0x01F4

},

Package (0x04)

{

ResourceTemplate ()

{

Register (FFixedHW,

0x01, // Bit Width

0x02, // Bit Offset

0x0000000000000020, // Address

0x03, // Access Size

)

},

0x06,

0x46,

0x015E

}

})

Method (_CST, 0, NotSerialized) // _CST: C-States

{

Store ("_CST: called", Debug)

Return (CSTW)

}

Method (ACST, 0, NotSerialized)

{

Store ("ACST: called", Debug)

Return (Package (0x05)

{

0x01,

0x03,

Package (0x04)

{

ResourceTemplate ()

{

Register (FFixedHW,

0x01, // Bit Width

0x02, // Bit Offset

0x0000000000000000, // Address

0x01, // Access Size

)

},

0x01,

0x41,

0x03E8

},

Package (0x04)

{

ResourceTemplate ()

{

Register (FFixedHW,

0x01, // Bit Width

0x02, // Bit Offset

0x0000000000000010, // Address

0x03, // Access Size

)

},

0x03,

0x43,

0x01F4

},

Package (0x04)

{

ResourceTemplate ()

{

Register (FFixedHW,

0x01, // Bit Width

0x02, // Bit Offset

0x0000000000000020, // Address

0x03, // Access Size

)

},

0x06,

0x46,

0x015E

}

})

}

-- If you are concerned that you are not getting lower P-states, presently I believe they will not be reached because OS X seems busy all the time. Instead of P-states I suggest looking at the HWMonitor's Core Package Watt use as that might be a better indication of your current state. If you google about detecting SpeedStep in OS X you will see that it is not that easy to get an accurate reading.

You should have something similar, adjusted for the number of CPUs, cores and threads, of course. If not then your basic SSDT setup is not correct and needs to be fixed. That is really beyond the subject of our discussion here.

Posted 11 January 2014 - 03:44 PM

You know that's way too much information and most of it is not related so please edit the post to make it easier for everyone. Just keep the CPU and ACPI related items.

Also, I should've noted that AICPMI should be loaded manually after the system is booted, as it makes it easier to track changes.

Lastly, you can see that there's a new P-state (32) beside the 12 and 44 now. You should let your system run for a bit to see what happens and whether other states show up, while you are normally using it (whatever you do with it).

Posted 11 January 2014 - 05:10 PM

Any tips on getting rid of the X86PlatformPlugin::getCPUCStates – C001 ACST and _CST evaluations failed! errors for CPUs C001 to C00B? That's the only step I'm falling down on.

I tried the Method ACST that Pike posted on his blog but it didn't change anything.

As it stands, I now have two states: 12x and 32x (before this I only had 32x). However the CPU stays at 12x no matter the load.

I presume you are not using NullCPUPM, correct?

I would check that the generated SSDT actually refers to the right processor identifiers and their location in the ACPI tree.

Ideally extract your original SSDT and see what they have done in it and how, then mimic that. It is possible that the naming conventions created by the script don't match the original DSDT/SSDT layout.

On my motherboard (EVGA) I do not have to do anything with SSDT and I get couple of C-states. Yet when I use the script, it does not initialize any of them and I get the same error just the CPU identifiers are different. That's why I suggest looking at your original SSDT first for reference.

Posted 11 January 2014 - 05:18 PM

Any tips on getting rid of the X86PlatformPlugin::getCPUCStates – C001 ACST and _CST evaluations failed! errors for CPUs C001 to C00B? That's the only step I'm falling down on.

I tried the Method ACST that Pike posted on his blog but it didn't change anything.

As it stands, I now have two states: 12x and 32x (before this I only had 32x). However the CPU stays at 12x no matter the load.

I also got this message until I generated a SSDT using ssdtPRGen.sh, which adds an ACST method. But now, as with you my CPU is nailed at x12. As the script does more than adding this method, how would a fix with only adding ACST look like? I am no ACPI expert, so I simply don't know how to do it.

Posted 11 January 2014 - 05:46 PM

Riley Freeman

InsanelyMac Legend

Members

1,070 posts

Gender:Male

Location:The Streets

@frankiee: I got that error after I used ssdtPRGen.

@omni: No NullCPUPM here. I removed DropSSDT from my Chameleon plist, moved the generated SSDT.aml out of Extra and rebooted using my stock SSDT. No errors and the states seem to be populated in IORegExp. However, I'm still stuck at 12x.

But I have a new warning in the system log: X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1

Posted 11 January 2014 - 06:43 PM

omni

InsanelyMac Sage

Members

286 posts

Gender:Male

@frankiee

You should manually load AICPMI once the system is up and not leave it in the /S/L/E or /E/E to boot up with. I thought Pike fixed the KP, as they usually happen when MSR is not present in a specific CPU family.

@Riley Freeman,

I'm ignoring 0x1AD MSR for now because mine isn't correct according to Pike either, and focusing on getting C- and basic P- states first.

Something is not occurring in your setup because the C-State residencies are 0x0 and they shouldn't be. Can you please check your kernel log and make sure that you are not getting Unknown CPU: ... anywhere?

X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1 - I get as well, have yet to look into it, but it seems it might relate to 0x1AD.

I'm going to update my original post to include further instructions, as we have to make sure your IO registry contains C- and P- states else there's little point to this.

Posted 11 January 2014 - 07:31 PM

frankiee

InsanelyMac Sage

Members

321 posts

Gender:Male

Location:Earth

Interests:Everything

@frankiee

You should manually load AICPMI once the system is up and not leave it in the /S/L/E or /E/E to boot up with. I thought Pike fixed the KP, as they usually happen when MSR is not present in a specific CPU family.

Loading the kext with kextload - after booting - gave me the following output:

Posted 11 January 2014 - 10:10 PM

Are you guys actually using the computer for a few minutes and doing normal things as you would, before reading the AICPUPMI?

Sure, I even did a Geekbench run which in fact turned out to be at 1/3 of what it was before. On a side note, when I try to run Geekbench _after_ running AICPUPMI my machine badly KPs: Monitor goes black and just restarts.

Posted 11 January 2014 - 11:34 PM

omni

InsanelyMac Sage

Members

286 posts

Gender:Male

Sure, I even did a Geekbench run which in fact turned out to be at 1/3 of what it was before. On a side note, when I try to run Geekbench _after_ running AICPUPMI my machine badly KPs: Monitor goes black and just restarts.

Another line in the log caught my attention:

kernel[0]: IOPPF: AppleIntelCPUPowerManagement mode

For Ivy-E, shouldn't that be XCPM mode?

As far as I know, only Haswell supports XCPM, while even the Trashcan Pro uses AICPM.