Xnu CPU Power Management

Some time ago I blogged about XCPM aka Xnu CPU Power Management and I have been digging ever since the first Developer Preview of Mavericks, but I never shared what I know about it. And now that OS X 10.9 Mavericks GM (Golden Master) is released to registered developers, I think that we should start sharing everything we know. People who want to know more about XCPM should also come back, from time to time, because this is only a kick-off blog article. Meaning that more updates will be added in the near future.

Ok. First of all. XCPM is initialised and controlled through the following functions in the XNU kernel (mach_kernel) – no longer with help of AppleIntelCPUPowerManagment.kext:

_xcpm_idle
_xcpm_signal_cpu
_xcpm_select_cpu
_xcpm_cpu_halt
_xcpm_exit_halt
_xcpm_exit_halt_to_off
_xcpm_interrupt_prewake_applicable
_xcpm_monitor_init
_xcpm_quiesce
_xcpm_apply_mbd
_xcpm_restore_mbd
_xcpm_fi_init
_xcpm_fi_update
_xcpm_get_ratio
_xcpm_transform_vector
_xcpm_resolve_limits
_xcpm_get_pkg_max
_xcpm_accumulate_pstate_ctrs
_xcpm_update_last_pstate_time
_xcpm_enable_pstate_ctrs
_xcpm_resolve_pstate
_xcpm_get_deadline
_xcpm_timer
_xcpm_urgency
_xcpm_dvfs_transfer_load
_xcpm_dvfs_clear_transferred_load
_xcpm_dvfs_start
_xcpm_dvfs_configure
_xcpm_dvfs_init_deadlines
_xcpm_dvfs_pause
_xcpm_dvfs_resume
_xcpm_qos_name2id
_xcpm_qos_id2name
_xcpm_dvfs_calibrate
_xcpm_set_max_bus_delay
_xcpm_get_max_bus_delay
_xcpm_set_max_int_delay
_xcpm_get_max_int_delay
_xcpm_ubpc_read
_xcpm_ubpc_config
_xcpm_bootstrap
_xcpm_perf_bias_set
_xcpm_perf_bias_get
_xcpm_init
_xcpm_register_dispatch_table
_xcpm_init_complete
_xcpm_enabled
_xcpm_cpu_model_get
_xcpm_ioctl_init
_xcpm_cpu_control
_xcpm_callbacks_register

There is however still nothing to be found in the currently available/released XNU source code. Unfortunately. There is no osfmk/x86_64/xcpm directory and thus files like: osfmk/x86_64/xcpm/xcpm_idle.c and osfmk/x86_64/xcpm/xcpm_dvfs.c are missing. We just have to wait for the next update.

Update:

Great. Apple released the source code of OS X 10.8.5 (xnu-2050.48.11) and 10.9.0 (xnu-2422.1.72) and now the xcpm directory is there… but that is all there is because the directory is (still) empty!

Update-3:

Apple released the source code of OS X 10.9.2 (xnu-2422.90.20) but unfortunately for us… the xcpm directory is still empty!

AppleIntelCPUPowerManagement.kext
We’ve long been using/relying on AppleIntelCPUPowerManagement.kext but that is no longer used for properly configured XCPM. In fact. The kext isn’t even loaded anymore because Apple now sets IOResources property intel_cpupm_matching to 3. Previously this was set to 0 and thus the match in AppleIntelCPUPowerManagment.kext/Contents/Info.plist fails:

	<key>IOKitPersonalities</key>
	<dict>
		<key>IntelCPUPowerManagement</key>
		<dict>
			<key>CFBundleIdentifier</key>
			<string>com.apple.driver.AppleIntelCPUPowerManagement</string>
			<key>IOClass</key>
			<string>AppleIntelCPUPowerManagement</string>
			<key>IOMatchCategory</key>
			<string>AppleIntelCPUPowerManagement</string>
			<key>IOPropertyMatch</key>
			<dict>
				<key>intel_cpupm_matching</key>
				<integer>0</integer>
			</dict>
			<key>IOProviderClass</key>
			<string>IOResources</string>
			<key>IOResourceMatch</key>
			<string>IOKit</string>
		</dict>
	</dict>

How do I know that it works like this? Easy. Open pal_routines.h and look for this snippet:

/* Include a PAL-specific header, too, for xnu-internal overrides */
#include <i386/pal_native.h>

extern boolean_t virtualized;
#define PAL_VIRTUALIZED_PROPERTY_VALUE 4

/* Allow for tricky IOKit property matching */
#define PAL_AICPM_PROPERTY_NAME "intel_cpupm_matching"
static inline void
pal_get_resource_property(const char **property_name, int *property_value)
{
        *property_name = PAL_AICPM_PROPERTY_NAME;
        *property_value = PAL_AICPM_PROPERTY_VALUE;
        if (virtualized)
                *property_value = PAL_VIRTUALIZED_PROPERTY_VALUE;
}

It gets called from the init routine in IOServices.cpp:

bool IOResources::init( OSDictionary * dictionary )
{
    // Do super init first
    if ( !super::init() )
        return false;

    // Allow PAL layer to publish a value
    const char *property_name;
    int property_value;

    pal_get_resource_property( &property_name, &property_value );

    if( property_name ) {
	OSNumber *num;
	const OSSymbol *	sym;

	if( (num = OSNumber::withNumber(property_value, 32)) != 0 ) {
	    if( (sym = OSSymbol::withCString( property_name)) != 0 ) {
		this->setProperty( sym, num );
		sym->release();
	    }
	    num->release();
	}
    }

    return true;
}

And lastly. Look at this snippet from pal_native.h:

#define PAL_AICPM_PROPERTY_VALUE 0

That sets it to 0. Again. This is still from OS X 10.8 (currently available) source code. Not Mavericks. But you understand what Apple changed. Don’t you 😉

Good news
Now the good news. AppleIntelCPUPowerManagement.kext is no longer used and you may even remove it. So why is this good news for us? Well. I guess that we all remember the days that we had to use NullCPUPowerManagement.kext because Apple writes to MSR 0xE2 in it. A problem located/solved by Sam (RevoGirl) after she figured out how to patch AppleIntelCPUPowerManagement.kext and some time later the BIOS. However. This may no longer be required. I mean. Apple basically solve it for us. Pretty sweet.

We can now even disabled EIST, Turbo and the Cn states in the (UEFI) BIOS and XCPM will still work. A big change.

plugin-type
Let us go back to Ivy Bridge power management for a sec, which introduced a new property called plugin-type. Apple used a _DSM (Device Specific Method) in one of their ACPI tables to trigger additional plugins to load (X86PlatformPlugin.kext and X86PlatformShim.kext). And we still need to set this property, otherwise the plugins won’t load (matching will fail) and you end up seeing this error in system.log:

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 unsupported

ACPI_SMC_PlatformPlugin.kext
No. We no longer need it. It is no longer required to have ACPI_SMC_PlatformPlugin.kext loaded. This also means that property Supported Features/Stepper CPU won’t be set, but you need to set plugin-type or you will get the above error.

AppleSMBusPCI.kext
No. We no longer need it. It is no longer required to have AppleSMBusPCI.kext loaded.

AppleSMBusController.kext
Yes. We still need it so make sure that it is getting loaded (run kextstat).

AppleSMCPDRC.kext
No. We no longer need it. It is no longer required to have AppleSMCPDRC.kext loaded.

AppleLPC.kext
Yes. We still need it so make sure it is getting loaded (run kextstat). Please note that Apple is using a different device-id (0x9c43) and we/most of us are using 0x8c44 so it will match differently. Or not at all.

AppleSMC.kext
I missed quite a few of SMC keys (see below) but the thing is that it isn’t always complaining about the missing keys, but I am still trying to figure out why this is. And here is the list of SMC keys that it complained about:

F0Ac, len: 2, type: [fpe2], data: 1217 (bytes 13 04)	| Base64: EwQ=
PC0R, len: 2, type: [sp78], data: (bytes 09 3a)		| Base64: CTo=
PM0C, len: 2, type: [sp78], data: (bytes 01 0a)		| Base64: AQo=
PO0R, len: 2, type: [sp78], data: (bytes 08 ad)		| Base64: CK0=
PZ0F, len: 4, type: [flt ], data: (bytes 66 96 00 41)	| Base64: ZpYAQQ==
PZ0E, len: 4, type: [flt ], data: (bytes 00 00 e0 41)	| Base64: AADgQQ==
PZ1F, len: 4, type: [flt ], data: (bytes 00 00 30 3e)	| Base64: AAAwPg==
PZ1E, len: 4, type: [flt ], data: (bytes 06 67 f6 40)	| Base64: Bmf2QA==
PSTR, len: 2, type: [sp78], data: (bytes 08 49)		| Base64: CEk=
PDTR, len: 2, type: [sp78], data: (bytes 0c 92)		| Base64: DJI=
MSAc, len: 2, type: [ui8 ], data: 0 (bytes 00)		| Base64: AA==
MSAf, len: 2, type: [fp6a], data: (bytes 00 00)		| Base64: AAA=
MSAg, len: 2, type: [ui8 ], data: 0 (bytes 00)		| Base64: AA==
MSAj, len: 2, type: [fp88], data: (bytes 00 00)		| Base64: AAA=
MSPA, len: 2, type: [fp6a], data: (bytes 00 00)		| Base64: AAA=
MSHT, len: 1, type: [ui8 ], data: 0 (bytes 00)		| Base64: AA==
DM0T, len: 2, type: [hex_], data: (bytes 00 00)		| Base64: AAA=
WOr0, len: 1, type: [si8 ], data: (bytes ff)		| Base64: /w==
WOw0, len: 1, type: [si8 ], data: (bytes ff)		| Base64: /w==
SBFL, len: 4, type: [hex_], data: (bytes 00 00 00 00)	| Base64: AAAAAA==
TCXC, len: 2, type: [sp78], data: (bytes 47 08)		| Base64: Rwg=
Ts0S, len: 2, type: [sp78], data: (bytes 26 33)		| Base64: JjM=
TH0F, len: 2, type: [sp78], data: (bytes dd 20)		| Base64: 3SA=
TB0T, len: 2, type: [sp78], data: (bytes 21 99)		| Base64: IZk=
B0AC, len: 2, type: [si16], data: (bytes 00 00)		| Base64: AAA=
B0AV, len: 2, type: [ui16], data: 92 (bytes 21 5c)		| Base64: IVw=
B0RM, len: 2, type: [ui16], data: 230 (bytes 1c e6)		| Base64: HOY=
BRSC, len: 2, type: [ui16], data: 100 (bytes 00 64)		| Base64: AGQ=
B0St, len: 2, type: [hex_], data: (bytes 40 e0)		| Base64: QOA=
BIMX, len: 2, type: [ui16], data: 255 (bytes 7f ff)		| Base64: f/8=
MSMD, len: 1, type: [ui8 ], data: 1 (bytes 01)		| Base64: AQ==
MSMN, len: 1, type: [fp6a], data: (bytes 00 00)		| Base64: AAA=
ACIC, len: 2, type: [ui16], data: 128 (bytes 0b 80		| Base64: C4A=
MSMF, len: 1, type: [ui8 ], data: 3 (bytes 03)		| Base64: Aw==
DICT, len: 1, type: [flag], data: (bytes 00)		| Base64: AA==

This list may be longer/shorter for you, since it depends on the version of FakeSMC.kext that you are using, and the keys that you already added yourself.

Note: FakeSMC.kext doesn’t report the reads of the above SMC keys. Not at every startup. This may be due caching or the fact that FakeSMC.kext isn’t loading early enough. This is why I would like to suggest to rename FakeSMC.kext to AppleEmulator.kext and changes the source code in such way that it loads properly aka in time for XCPM.

Mach Kernel

Now we know that XCPM is baked into the mach_kernel. For both OS X 10.8.5 and OS X 10.9 Mavericks and thus I skimmed through the mach_kernel and found a couple of boot arguments that we can use:

-xcpm
-xcpm_assert (sets machdep.asserts to 1)
-xcpm_assert_trace (sets machdep.asserts_traced to 1)
-xcpm_ignore_fv (ignores the frequency vectors)
-xcpm_ipi
idlehalt
cstates

sysctl

The command line tool sysctl now also includes the MIB name (Management Information Base) machdep.xcpm:

sysctl machdep.xcpm

And running the above command in a terminal window dumped this:

machdep.xcpm.mode: 1
machdep.xcpm.asserts_enabled: 0
machdep.xcpm.asserts_traced: 0
machdep.xcpm.cpu_wakeup_energy_cost_selector: 0
machdep.xcpm.disable_quiesce: 0
machdep.xcpm.mp_match: 0
machdep.xcpm.disable_idle_self_select: 0
machdep.xcpm.mp_load_txfr_coeff: 128
machdep.xcpm.scalability_cpi_threshold: 4
machdep.xcpm.scalability_cpi_demotion_threshold: 5
machdep.xcpm.scalability_reeval_interval: 1000
machdep.xcpm.scalability_eval_ratio_min: 17
machdep.xcpm.scalability_detection_enabled: 0
machdep.xcpm.hard_plimit_max_100mhz_ratio: 38
machdep.xcpm.hard_plimit_min_100mhz_ratio: 8
machdep.xcpm.soft_plimit_max_100mhz_ratio: 38
machdep.xcpm.soft_plimit_min_100mhz_ratio: 8
machdep.xcpm.ratio_changes_hf: 0
machdep.xcpm.ratio_changes_lf: 0
machdep.xcpm.ratio_change_limited: 0
machdep.xcpm.ratio_change_hf_limit: 2
machdep.xcpm.ratio_change_lf_limit: 1
machdep.xcpm.ratio_change_ratelimit_ns: 500000
machdep.xcpm.ratio_changes_total: 33246
machdep.xcpm.maxbusdelay: 4294967295
machdep.xcpm.maxintdelay: 0
machdep.xcpm.mbd_mode: 1
machdep.xcpm.mbd_applications: 437
machdep.xcpm.mbd_relaxations: 437
machdep.xcpm.forced_idle_ratio: 100
machdep.xcpm.forced_idle_period: 30000000
machdep.xcpm.deep_idle_log: 0
machdep.xcpm.qos_txfr: 1
machdep.xcpm.q_migration_ttd_min: 1000000
machdep.xcpm.q_migration_ttd_max: 100000000
machdep.xcpm.preidle_spin_tsc: 0
machdep.xcpm.qos_ratio_change_limited: 0
machdep.xcpm.qos_ratio_change_hf_limit: 8
machdep.xcpm.qos_ratio_change_lf_limit: 1
machdep.xcpm.qos_ratelimiting_enabled: 1
machdep.xcpm.quiesce_trace: 0
machdep.xcpm.deep_idle_count: 0
machdep.xcpm.deep_idle_last_stats: n/a
machdep.xcpm.deep_idle_total_stats: n/a

Running sysctl machdep.xcpm.mode shows us if XCPM is active and sysctl machdep.xcpm.ratio_changes_total shows us the number of ratio changes. Zero means that XCPM is not functioning/operational. In that case you should also check the former MIB as well.

UEFI BIOS Settings

Like I said earlier. We can now disable: EIST, Turbo, and CST settings in our UEFI BIOS and still enjoy using XCPM, simply because the old days are over. That is for hardware with the following product-name:

MacBookAir, iMac, Macmini, MacBook Pro and MacPro

And one of the following board-id‘s:

Mac-00BE6ED71E35EB86 – iMac13,1
Mac-031AEE4D24BFF0B1 – Macmini6,1
Mac-031B6874CF7F642A – iMac14,1 (Haswell/FrequencyVectors)
Mac-189A3D4F975D5FFC – MacBookPro11,1 (Haswell/FrequencyVectors)
Mac-27ADBB7B4CEE8E61 – iMac14,2 (Haswell/FrequencyVectors)
Mac-2E6FAB96566FE58C – MacBookAir5,2
Mac-35C1E88140C3E6CF – MacBookAir6,1 (Haswell/FrequencyVectors)
Mac-3CBD00234E554E41 – MacBookPro11,2 (Haswell/FrequencyVectors)
Mac-2BD1B31983FE1663 – MacBookPro11,3 (Haswell/FrequencyVectors)
Mac-4B7AC7E43945597E – MacBookPro9,1
Mac-66F35F19FE2A0D05 – MacBookAir5,1
Mac-6F01561E16C75D06 – MacBookPro9,2
Mac-77EB7D7DAF985301 – iMac14,3 (Haswell/FrequencyVectors)
Mac-7DF21CB3ED6977E5 – MacBookAir6,2 (Haswell/FrequencyVectors)
Mac-7DF2A3B5E5D671ED – Mac??? (2012 model)
Mac-AFD8A9D944EA4843 – MacBookPro10,2
Mac-C3EC7CD22292981F – MacBookPro10,1
Mac-F60DEB81FF30ACF6 – MacPro6,1
Mac-F65AE981FFA204ED – Macmini6,2
Mac-FC02E91DDD3FA6A4 – iMac13,2

This also means that the boot argument -xcpm_ignore_fv is only supported/works with certain board-id’s. This boot option will disable all P-States between the lowest (800 MHz) and highest non-Turbo P-State (in my case above 800 MHz and below 3.4 GHz)

Native Power Management

Some folks think to have “native” power management on their Haswell setups, just because their boot loader isn’t loading a DSDT and/or (generated) SSDT with proper data, but most of them are wrong. Sure. AICPUPMI may show something like this:

CPU P-States [ 8 34 35 (36) 37 ]
iGPU P-States [ 4 7 8 9 (10) 11 12 14 15 16 17 25 ]

But all it means is that a limited number of P-States is used. It says absolutely nothing about what is driving it and if low power states (C-States) are even used or not. A next write-up from me will make this clear for everyone. Well. That is my intention.

Note: The above iGPU data shows a 4, but that is wrong since the installed desktop processor can’t scale down to 200 MHz, it is however part of the AGPM data and thus we end up seeing it. A new update of AppleIntelCPUPowerManagementInfo.kext (soon to be released) will take care of it. Yes it can (link).

This is still a limited amount of information. Stuff that I gathered about XCPM during my use of OS X 10.9 Mavericks, but I am pretty sure that many blog posts and forum threads will show in the near future. And of course. You can count on me being one of the first to push out more updates about XCPM. All I need to do is to make some time for it, but I didn’t want to wait any longer with this information/data but this has to be it for today (it was a lot of work).

Update

_xcpm_core_scope_msrs is defined as 0xE2 so it seems like people with a locked (UEFI) BIOS are screwed once again. Maybe someone with a Z77 board with locked UEFI BIOS can verify this for us. And yes indeed. XCPM also supports Ivy Bridge processors.

Update-2:
I have setup my hack as a Macmini7,1 MacBookPro11,1 and now I get this:

AICPUPMI:
CPU P-States [ 8 (21) 34 35 36 37 38 ]
iGPU P-States [ 7 8 9 10 11 12 13 14 15 16 17 18 19 (23) 24 25 ]

Showing all iGPU P-States, but still a limited number (7) of CPU states. Better than nothing. This with every PM option (EIST/Turbo and C-States) disabled in the UEFI BIOS, but it is still a work in progress.

Update-3:
A new error is triggered in OS X 10.9.2 Mavericks (Build 13C32) when you set Name (APLF, Zero) to anything but Zero:

XCPM: P-state table mismatch (error:0x8)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x8
X86PlatformShim::start - Failed to send PStates

You may also see:

X86PlatformShim::start - Failed to send stepper

Which means that the FrequencyVectors data in, for example, the Mac-F60DEB81FF30ACF6.plist is missing.

85 thoughts on “Xnu CPU Power Management

      • Pike , sorry wich kext ACPM ?
        I have delete null cpu from my sistem ( x79 , i73930k) and have again ACPM unpatched , but i see one pstate ( i am on overclock to 47x ) only 47x .
        Have you a suggestion ?
        Sorry for my bad english

      • I was under the impression that power management was working for you. At least that is what people told me. I mean was’t it RampageDev who helped you already?

      • In fact. mine has been a test to see if the GM without the null cpu on x 79 I had a kernel panic, and so it was, so I thought I’d give this news to rampage dev, but the strange thing is that I only see a cpu null pstate, while nothing I see all pstate.
        Have you a suggestion?
        Thanks Friend

      • Ok. So without NullCPUPowerManagment.kext you got a KP. Now the question is what model identifier and board-id are you using, because you don’t want AppleIntelCPUPowerManagement.kext to load. You want XCPM to work with the board-id of the new Mac Pro 😉

      • no no Pike , without NullCpu i dont have kernel panic ( i use ACPM unpatched ) , maybe you dont unterstand my english , and sorry for this.( i am italian )
        I want to say that without the null cpu I see only a pstate, and I have no kernel panic.
        While if I put Null cpu, I see all the pstate, but I see them from a wobble with Hardware monitor ( branch Kozlek )and not with Mrdumper Kext.
        PS: I use Macpro 5,1

      • Ah right. So with NullCPUPowerManagment.kext you see all/more P-States than without it. This means that your UEFI BIOS is controlling the power management. Not OS X. You can check this by disabling EIST in the UEFI BIOS.

        In case you want OS X to control power management, which I would do, then use the board-id and model info of the new Mac Pro (see my blog for the actual smbios data). That should work for 10.8.5 and 10.9

        p.s. When MSRDumper.kext isn’t showing any P-States then something is obviously wrong.

      • Pike please listen me , I disabled all, C1E c2 c3 and c7 also speed step, to no avail, with these settings disabled I only see him step up, only 47x.
        what do you recommend? I have to change SMBIOS?

  1. Pingback: MiniHack Core i5-4430 - Zotac H87 ITX 8GB RAM - GT 240 - Page 2

  2. Just wanted to say thanks for all of this work.
    It has really educated me a lot (at least the parts I understand so far!) and has helped me to (a) understand why my H87 Zotac would not boot 10.8.5 and 10.9, and (b) then to get it booting and now to be using xcpm. In case of interest this is my terminal output of the xcpm data from my i5 4430:
    daves-iMac:~ dave$ sysctl machdep.xcpm
    machdep.xcpm.mode: 1
    machdep.xcpm.asserts_enabled: 0
    machdep.xcpm.asserts_traced: 0
    machdep.xcpm.cpu_wakeup_energy_cost_selector: 0
    machdep.xcpm.disable_quiesce: 0
    machdep.xcpm.mp_match: 0
    machdep.xcpm.disable_idle_self_select: 0
    machdep.xcpm.mp_load_txfr_coeff: 128
    machdep.xcpm.scalability_cpi_threshold: 4
    machdep.xcpm.scalability_cpi_demotion_threshold: 5
    machdep.xcpm.scalability_reeval_interval: 1000
    machdep.xcpm.scalability_eval_ratio_min: 17
    machdep.xcpm.scalability_detection_enabled: 0
    machdep.xcpm.hard_plimit_max_100mhz_ratio: 32
    machdep.xcpm.hard_plimit_min_100mhz_ratio: 8
    machdep.xcpm.soft_plimit_max_100mhz_ratio: 32
    machdep.xcpm.soft_plimit_min_100mhz_ratio: 8
    machdep.xcpm.ratio_changes_hf: 0
    machdep.xcpm.ratio_changes_lf: 1
    machdep.xcpm.ratio_change_limited: 0
    machdep.xcpm.ratio_change_hf_limit: 2
    machdep.xcpm.ratio_change_lf_limit: 1
    machdep.xcpm.ratio_change_ratelimit_ns: 500000
    machdep.xcpm.ratio_changes_total: 474676
    machdep.xcpm.maxbusdelay: 0
    machdep.xcpm.maxintdelay: 0
    machdep.xcpm.mbd_mode: 1
    machdep.xcpm.mbd_applications: 0
    machdep.xcpm.mbd_relaxations: 0
    machdep.xcpm.forced_idle_ratio: 100
    machdep.xcpm.forced_idle_period: 30000000
    machdep.xcpm.deep_idle_log: 0
    machdep.xcpm.qos_txfr: 1
    machdep.xcpm.q_migration_ttd_min: 1000000
    machdep.xcpm.q_migration_ttd_max: 100000000
    machdep.xcpm.preidle_spin_tsc: 0
    machdep.xcpm.qos_ratio_change_limited: 0
    machdep.xcpm.qos_ratio_change_hf_limit: 8
    machdep.xcpm.qos_ratio_change_lf_limit: 1
    machdep.xcpm.qos_ratelimiting_enabled: 1
    machdep.xcpm.quiesce_trace: 0
    machdep.xcpm.deep_idle_count: 0
    machdep.xcpm.deep_idle_last_stats: n/a
    machdep.xcpm.deep_idle_total_stats: n/a
    daves-iMac:~ dave$ sysctl machdep.xcpm.mode
    machdep.xcpm.mode: 1
    daves-iMac:~ dave$ sysctl machdep.xcpm.ratio_changes_total
    machdep.xcpm.ratio_changes_total: 494470

  3. (see my blog for the actual smbios data). That should work for 10.8.5 and 10.9)
    hello I can indicate, I would try to x79 I also tried with a SSDT but I only see a P-state cm checked MSRDumper.kext

      • Sorry Pike , but i dont unterstand .
        Please , but i have to or not to change my SMBIOS from 5.1 to 6.1? can you please explain step by step what should I do? if they do not disturbe you, Thanks of heart

      • Yes. You should use MacPro6,1 and its board-id, but you must also inject the “plugin-type” property. The latter is done for all Ivy Bridge processor and your processor is no exception to this rule (see ssdtPRGen.sh generated SSDT’s for Ivy Bridge).

  4. Hello Pike
    SMBIOS Mac Pro 6.1
    Generated SSDT injectato “plug-type”
    Result MSRDumper.kext only 32
    What else can I try
    thanks

  5. Pike Sorry forgot to tell you when I create the SSDT I have this error:
    Warning: ‘cpu-type’ may be set improperly (0×0501 instead of 0×0601)
    Warning: ‘board-id’ [Mac-F221BEC8] is not supported by Sandy Bridge PM

  6. thanks for this information. i just updated a gigabyte H55M-S2V to 10.8.5. i’m using clover v980 as the bootloader. after the update i kept getting AICPM KP’s, and after trying all the normal things, i found this xcpm information. i removed AICPM, did not use nullcpupowermanagement, and the machine is booting fine.

  7. Iv a question about “F0Ac” SMC Key. I found it on the SMC Dumb list from iMac13,2.

    The question is… why this KEY provides to Kernel Panic on my iMac13,2 Perfect Hackintosh? 🙂

  8. Thankyou, thankyou, thankyou!!

    I told Clover to drop the power management SSDT and not to generate any P- or C- states and now my GA-Z87-HD3 with a Haswell i7-4790 is ticking along with proper power management and steps from 800MHz up to 3.8GHz nicely.

  9. Hi Pike!

    I can’t use -xcpm on my i5 3210M.
    I use MBP 9,2 SMBios, and disable AICPMpatch (Clover), and when a add -xcpm my Hack reboot instantly.

    Why?

    • Instant reboots that are related to power management are usually caused by a locked MSR. You need a Clover kernel patch. Don’t ask. I have no idea how that works in Clover. Sorry.

      • Ok so you now have the kernel patch in place and the -xcpm boot argument is working (IOPPF: XCPM mode) but you are using -xcpm_ignore_fv as well, and that basically disables XCPM – hence you get the KP in AppleIntelCPUPowerManagement.kext What you should do is fix the errors by using a supported model/board-id, otherwise it cannot find the FrequencyVectors, and run ssdtPRGen.sh with the correct settings.

  10. Oh nice!

    I use here this SMBios: Mac-6F01561E16C75D06 – MacBookPro9,2
    Even using -xcpm, is necessary use SSDT file?

    Thanx

  11. Hello Pike, so if I understand this post correctly appleintelcpupowermanagement is not used anymore in Yosemite right? So I got a question for you, I set up a system based on h67 chipset and i7-2600k sandy bridge cpu. I am using clover uefi and Yosemite final relase. I generated an ssdt with the well known generator script and put it in uefi, I removed generate c-states and p-states from clover plist, I also removed ssdt drop tables as I am using the generated ssdt. I patched the aicpm for the MSR 0xE2 problem. I can see from my log that:

    1) Inserting SSDT.aml from EFI\CLOVER\ACPI\patched … Success

    and

    2 ) ACPI_SMC_PlatformPlugin::start – waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out

    So my guess is all the ssdt and aicpm stuff is useless in yosemite right? Yet the system boots up and I can see speedstep is working through 16 and 34 p-states.

    I also noticed during kext installation of AICPUPM a message like “appleintelcpupowermanagement.kext has no info.plist”. Is it possible that since it’s not used anymore that Apple removed the plist where we found info for resource matching and so the above mentioned time out error?

    Is there a way to make yosemite use AICPUPM in Yosemite with Sandy Bridge?

    What is controlling the power management at the moment if neither XCPM nor AICPUPM are working on this machine? I don’t have NULLCPUPOWERm either.

    Thanks for your time.

    • This blog article is about XCPM, the kernel power management driver. Not the AppleIntelCPUPowerManagement.kext which is Apple’s power management driver for none XCPM mode, and yes it is still used/required for Sandy/Ivy Bridge processors. So is the generated SSDT.

      What I can say about the (Clover) patch for AppleIntelCPUPowerManagement.kext is that it should not be used. Better is to get a patched (read unlocked) BIOS because all the (Clover) patch does is stop the reboot loop, but power management is not 100% functional.

      In short; Yosemite includes AppleIntelCPUPowerManagement.kext for Sandy/Ivy Bridge processors, and you should definitely use it for your i7-2600K.

      • Thanks for the info. So I must conclude that appleintelcpupm is not working correctly on my system with a simple patch. Question: how can I unlock the bios? Is there a tool? Thanks

      • Patched copies of AppleIntelCPUPowerManagement.kext simply replace MSR (0xe2) writes with a couple of NOP instruction. Not what a real unlocked UEFI BIOS does so Google for unlocked BIOS with your motherboard brand/model. That usually works.

      • Patched copies of AppleIntelCPUPowerManagement.kext simply replace MSR (0xe2) writes with a couple of NOP instruction. Not what a real unlocked UEFI BIOS does so Google for unlocked BIOS with your motherboard brand/model. That usually works.

  12. I have to add to my post that at the moment I have EIST enabled in bios along with TURBO and I am using a MacMini 5,1 smbios. I am not at home now to try disabling EIST. For sure I am not getting Turbo modes in Osx.

  13. Hi,

    I’m running into a power management issue. I recently built the xnu kernel for yosemite on my new 2014 MBP Haswell i7 retina. I referenced the instructions from here:

    http://shantonu.blogspot.com/2014/10/building-xnu-for-os-x-1010-yosemite.html

    I’ve been building xnu from source like this for years on my older machines. However, things are a lot different on this new 2014 MBP. The kernel compiled fine, but when I installed it via setting new `boot-args’ variable kcsuffix=.development and rebooted, my fans started running so fast that the computer sounded like a small jet aircraft. Because of this, I rebooted back into the stock kernel very quickly. I was afraid that the computer was just getting to hot. Once I’m back in the stock kernel, this machine runs virtually silent.

    Mr. pikeRAlpha,

    Do you have any idea why this is happening only with this newer computer? Is it an SMC issue with a self-compiled kernel? What can I do differently in this scenario, so I can boot my own kernels without the fans running so fast ?

    • Long story short:

      The XCPM source code is not included with the XNU kernel sources. Like I said in my blog article. Apple even removed the directory (osfmk/x86_64/xcpm/) in Yosemite 10.10. and without the in kernel power management driver… things happen to go bad.

      • Ok, my friend,

        Thanks for letting me know that. I don’t understand why Apple would remove that directory considering that they’re willing to publish the rest of the XNU kernel sources. Someone else even suggested to me to try resetting the SMC, but I don’t really want to take too many chances, considering that this is a brand new MacBookPro Haswell.

      • Yeah. Please don’t do that (resetting the SMC). This problem is really caused by the missing XCPM source code.

        What we can do is to extract and disassemble the missing XCPM code. A massive amount of work, but then people like you should be able to compile the XNU source code and link against a new private XCPM framework/library.

  14. Ok. Just out of curiosity, I have read that the XCPM code resides as firmware within these new macs, like the one I have. Is that true? To me, if that’s the case, then it’s on a chip on the logic board like everything else is on my MBP Haswell, i.e., my storage now on this machine is an SSD drive, as well as the 16GB of memory is directly on the logic board, etc… Therefore, how could the fact of me compiling the XNU source and booting that `alternate’ image effect the XCPM firmware in a way that, as I was describing, that it causes my fans to run too fast ? Seems a bit odd to me.

    • If that was the case then it would have worked with your self compiled kernel. But it doesn’t. Now look at the source code. Specifically i386_init.c

      void i386_init(void) {…) calls xcpm_bootstrap() and xcpm_init() in the compiled Apple kernel, but the public XNU source code calls power_management_init()

      It sucks. I know. However, this is what we have to work with. Perhaps if enough people complain about it, then Apple could add the missing source code… but I doubt that it will ever happen.

      p.s. Did you try to boot with -xcpm=0 ?

  15. Yeah. I’ve noticed that difference in the calls in the source before, since Mavericks. And also, no, I have not tried to boot with that argument. So, then I would set that as an nvram boot-args variable to turn off XCPM ? Is that what you mean?

  16. I can see by the dump of otool -tV that MSR 0xE2 is one of our critical areas of interest involving any kind of resolution. I agree with you completely on the notion that this could be way too overwhelming of an endeavor.

  17. Hello again. I patched my bios with uefitool (replaced that 75 with eb in the proper location) and now I don’t get the message (locked in bdmesg). However I still get this line: ACPI_SMC_PlatformPlugin::start – waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out in boot (dmesg). I also reinstalled appleintelcpupowermanagement.kext as I had patched the previous one and turned off EIST and TURBO in bios. I can see the cpu is changing p-states with Intel Power Gadget however I still don’t seem to get turbo modes.

    • Then you are not using the correct file. I checked it and it is there. As it should. Did you perhaps extract the kext from a patch (upgrade) package? Don’t do that. Make sure all files are there.

      • Now I reinstalled appleintelcpupowermanagement.kext , appleintelcpupowermanagementclient.kext and IOPlatformPluginFamily.kext (which containsACPI_SMC_PlatformPlugin.kext) with pacifist directly from Yosemite package downloaded from the app store. At reboot I got an error from clover: multiple patterns found and boot stuck at waiting for dsmos so I entered in efi partition and deleted all 10.6 10.7 10.8 and 10.9 directories from kexts leaving only “other” and 10.10. The system rebooted to desktop but still appleintelcpupowermanagement has no info.plist and time out. Also I don’t have the kext loaded, I can’t see it in kextstat.

  18. bingo man! I reinstalled osx and now everything works, even turbo boost. The question is: how do I reactivate speedstep and turbo boost in windows if I have to keep it disabled in bios?

    Edit: however I can only reach a p-state of 35 in turbo mode, no 36 37 nor 38

    p.s. I tried to install you aicpupminfo.kext and got kernel panic and a boot loop. I had to remove it to regain access to the machine.

    • You don’t necessarily need to disable EIST in the BIOS, but it helps you to determine if power management, driven by Apple PM software, is working or not.

      About the turbo states. I cannot help you with this. It also doesn’t belong here. First download and compile AppleIntelInfo.kext and then feel free to open a new issue against ssdtPRGen.sh

  19. is this ssdt table dropping before inserting ssdt.aml correct?

    5:809 0:000 Patch table: SSDT SataTabl
    5:809 0:000 SSDT len = 0x36D
    5:809 0:000 Patch table: SSDT Cpu0Ist
    5:809 0:000 SSDT len = 0x9AA
    5:809 0:000 Patch table: SSDT CpuPm
    5:809 0:000 SSDT len = 0xA92
    5:809 0:000 Drop tables from Xsdt, SIGN=XXXX TableID= Length=0
    5:809 0:000 Xsdt has tables count=7
    5:809 0:000 corrected XSDT length=92
    5:809 0:000 Inserting SSDT.aml from EFI\CLOVER\ACPI\patched … Success

      • The point is I don’t have drop ssdt in config.plist, I removed the SSDT part completely so I don’t know how else to prevent that Patch table SSDT or Drop tables from Xsdt. As for appleintelcpuinfo I had kernel panic when installing it. Now I get P States: 16, 25, 30, 34, 35 (I check with DPCI manager). I tried to enable smartups as I read it affects power management but nothing changed.

  20. appleintelcpuinfo now didn’t KP, I don’t know what happened yesterday. This is the log:

    Nov 18 13:02:44 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 35 36 ]
    Nov 18 13:02:45 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 35 36 37 ]
    Nov 18 13:02:53 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 34 35 36 37 ]
    Nov 18 13:02:58 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 34 35 36 37 ]
    Nov 18 13:03:05 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 25 34 35 36 37 ]
    Nov 18 13:04:01 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 34 ]
    Nov 18 13:04:03 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 34 35 ]
    Nov 18 13:04:04 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 25 34 35 ]
    Nov 18 13:04:08 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 23 25 34 35 ]
    Nov 18 13:04:12 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 23 25 34 35 36 ]
    Nov 18 13:04:14 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 23 25 34 35 36 37 ]
    Nov 18 13:04:15 Chriss-Mac-mini kernel[0]: AICPUPMI: CPU P-States [ 16 23 25 30 34 35 36 37 ]

    • Which looks perfectly fine. Don’t forget that getting more P-States – triggered by Apple’s power management driver aka XCPM or AppleIntelCPUPowerManagement.kext – isn’t necessarily better.

      • hmm, why not? It means that the 3800 mhz are never reached. If I run cinebench in windows 8 the cpu reaches 3800mhz and the result is 630 circa, in osx the result is 615.

      • The Intel Turbo Boost Technology states that the top turbo multiplier, in your case 38, should only be triggered when a single core is active. Which is clearly not the case with OS X, because there is sporadically only one core active. Mostly during boot time.

        Apple simply follows the rules, and what it does is right. Not to mention that Windows is a completely different kind of operating system so you cannot really compare the two.

    • There is nothing in your DSDT that controls or changes the behaviour of power management, but maybe you copied the kext to: /System/Library/Extensions and then you should see the top multiplier (38).

      • Hello. No I didn’t put the aicpupm kext in s/l/e, it was already there . The multiplier appeared after putting the DSDT in clover efi partition. One question, if you have an ivy bridge system with unlocked bios do you still need to patch the kernel?

  21. After googling a lot, I found your website describing the new power management in the Mac. I have a Yosemite MacBookAir 6,2 and after spiling some water on it, it seams that the thermal sensor blew out. This causes the kernel to think that the CPU is overheating and thus, it triggers the power management to throttle instructions in the hopes that it will reduce the CPU heat.

    Since the CPU is cold, I was wondering if I could avoid using the Intel power management features and was looking into NullCPUPowerManagement when I found this site. Would you be able to share some light into how to tweak/patch the installed kernel on my Mac to achieve this?

  22. Pingback: » Apple:Can I get the CPU temperature and fan speed from the command line in OS X?

  23. Hi,Pike…
    Nice to see you 3rd times!
    My motherboard is GA-B75M-D3V and my CPU is E3 1230 v2.I use your ssdtPRGen.sh to generate SSDT.aml to enable Speedstep and recently I would like to enable XCPM instead of AICPUPM.I tried the following way for this:
    1. Use vanilla X86PlatformPlugin.kext and your shell generated SSDT.aml and add -xcpm kernel flags,although XCPM is enabled but X86PlatformShim::start – Failed to send stepper.
    2. Use FakeCPUID with Haswell but failed…
    Any idea?
    THX.

    • The E3-1230 V2 is an Ivy Bridge processor and Ivy Bridge based processors have issues for which the -w argument was introduced. Also. Please use Github issues instead of reviving an old blog article 😉

  24. Pike.. lovee your work and many years ago Masterchief helped me with some SSDT GA-EP45 stuff.. a family of guniuses..

    I am having some issues getting me workstation upgraded from 10.6.8 to 10.11.3 with clover. It is a DX58so board with a w3680 and 12gb 3×8 kingston ECC ram

    I use a DSDT that was patched for the board and have found some SSDTs that were written for the w3680, and revogirl helped that guy so I am assuming it is goot to go but perhaps not for my board.

    I have everything up and running but get a couple issus I cant figure out.. SSDT or letting clover generate does not matter..

    if I downgrade the bios, set defaults, the upgrade to latest 5600, set only UEFI boot and AHCI and boot clover will report the w3680, turbo capable and has 26/26/27/27 for turbo states..

    if I go into bios and enable ECC under the performance / memory tab.. dont touch anything else.. and boot clover boot log shows the w3680, not turbo capable and has 0/0/0/0 for turbo states..

    just going back into bios and disabling ECC doesnt fix it… usually have to downgrade and upgrade back

    It never activates ECC, always shows as disabled in the system profiler but if I boot the system into a memtest86 thumbdrive I can test ECC and it works fine?

    I have tried both EFI and UEFI, mac pro 4,1 and 5,1 no differance..

    I am at the end of my rope.. all I can think of is that either something in clover is not playing well or intel has a bug in the bios that enabling anything in the performance area, ECC, turbo mulitpliers etc breaks something..

    any help would be appreciated.. reading what I can find until I have gone blind for the last couple weeks and trying to self solve is now beyond what little skill set I have.

    Thanks

      • Gracias.. Pike.. I understand you are busy and any assistance you can provide would be highly appreciated.

        I am noticing some addional power management related issues with clover and a gigabyte GA-EP45 board as well. if the bios settings for the cpu (8400) and memory are kept cold normal, no changes to clock, dividers (even to get the ram to rated speed) i.e. 800 ram that is designed to run at 1066 at 2.2v.. I mean change nothing.. the system seems happy and speed step is working and at idle activity the cpu fan drops to 850rpm.. generate p,c states etc.

        if I just change the divider to get the memory up to designed speed, running the cpu stock and raising ram voltage from its jadec to its published 2.2 for 1066 speed

        it looks as if the speedstep is working but cycling constantly and with high frequency even under no load and cpu fan runs at 2k plus all the time..

        it seems if clover sees the system outside of apples spec, some power managment must not be loaded or respected?

        I have still been working on the DX58 and I am convinced that there is either a bug in the intel bios.. or with clovers logic..

        I am envious.. I left the service after 20 years and my wife is from Alicante, we would have loved to move back to spain but she is teaching here and I am out of work.. the economy is poor and jobs are not plentiful for guys with my skillset here…

        thanks again for whatever help you can provide.

      • well one quick question then.. since this appears to be bios related.. since just turning on ECC in the bios is definitly killing turbo boost… if I dump pre boot tables with clover with ECC on and ECC off.. would it be straight forward to see a potential issue in the resulting tables?

        for someone that knows what they are looking at that is..

  25. Pingback: MacBook9,1 will be the first Mac ever to support HWP – 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