Haswell CPU/iGPU power management with a GA-Z87M-D3H

I have configured RevoBoot to match a 2013 MacBook Air model and noticed a couple of oddities after the first boot. Let me start by adding a first screenshot.
One with the MacBook Air serial number removed, of course. And when everything is configured correctly, then you shouldn’t see this error:

[AGPM Controller] unknownPlatform

Usually the result of using unknown/unsupported board-id’s. No problem here. I also have my AppleIntelCPUPowerManagementInfo.kext installed and thus I looked for the relevant processor data in /var/log/system.log:

AICPUPMI: Low Frequency Mode : 800 MHz
AICPUPMI: Clock Speed : 3400 MHz
AICPUPMI: Max Turbo Frequency: 3800 MHz

The lowest supported processor frequency for desktop processors is now also 800 MHz so we should get a lot lower P-States. Not here. Not now at least. The clock speed and maximum turbo frequency are ok. This tells me that the UEFI BIOS bug I see here – discussed later on – is a cosmetic only one (I think). Next up. iGPU data:

AICPUPMI: IGPU Current Freq..: 200 MHz
AICPUPMI: IGPU Max Frequency.: 350 MHz
AICPUPMI: IGPU Max Turbo Freq: 1200 MHz

This is also fine. How do I know this you ask? Well. You may not be aware of it – not so strange since there isn’t a single Google search result for it – but we actually have a debug boot flag for it. Try this:

debug=0x100 igdebug=0xff

Reboot and look for the following output (example):

IG:: updateTableEntry:NN entry = 5
IG:: updateTableEntry:NN frequency = 950
IG:: updateTableEntry:NN upTimer = 31250
IG:: updateTableEntry:NN upThresholdlimit = 25000
IG:: updateTableEntry:NN upStep = 1
IG:: updateTableEntry:NN downTimer = 31250
IG:: updateTableEntry:NN downThresholdlimit = 18750
IG:: updateTableEntry:NN downStep = 1

You should see one of these blocks for every supported frequency. I checked mine and they are all there. Oh and it supports Ivy Bridge as well.

Time to take a closer look at the P-State and iGPU P-State results:

AICPUPMI: CPU P-States [ (8) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 (34) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 (36) ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 (35) 36 ] GPU P-States [ (4) ]
AICPUPMI: CPU P-States [ 8 34 35 36 (37) ] GPU P-States [ (4) ]

Not exactly what I hoped for, but it is a start. The first thing that you’ll notice is that CPU power management isn’t working. Apparently that is, since every P-State between 9 and 33 is missing. CPU power management however is correctly registered, and that in the correct (XCPM) mode, since I found these two in system.log:

XCPM: registered

Please note that the (4) means 4 x 50 MHz aka 200 MHz. Which happens to be the lowest possible frequency for the iGPU. A deep sleep/wake cycle gave me this:

AICPUPMI: CPU P-States [ 8 34 35 36 (37) 38 ] GPU P-States [ 4 (9) 22 23 24 ]

Seems to be working, but I do seem to miss the top multiplier (38) for a single-core process at boot time – only showed up after a deep sleep/wake cycle. Weird. Possible due to this UEFI BIOS error:
Here the multipliers are dead wrong. Some of them are for the i7-4770K but the top multiplier is a duplication of the one below it. And even when I set the correct values manually, even then it doesn’t solve this problem. Not that I really care about it – seems to be a cosmetic only problem – since I see this in system.log:

MSR_TURBO_RATIO_LIMIT……(0x1AD) : 0x23242526

In layman terms: The MSR is initialised correctly, with the correct value, but you may want to check it when you use the default settings. Anyway. I also found this:

MSR_IA32_PERF_STATUS…….(0x198) : 0x17D300000800
MSR_IA32_PERF_CONTROL……(0x199) : 0x800

Meaning that my system boots in 800 MHz mode, this instead of using the top multiplier. I believe this to be another UEFI BIOS error because normally it would have been something like this:

MSR_IA32_PERF_STATUS…….(0x198) : 0x17D300002600
MSR_IA32_PERF_CONTROL……(0x199) : 0x2600

Maybe Gigabyte fixed this in the UEFI BIOS updates they have avilable for download on their website, but since I don’t have MS Windows… I cannot update mine. Still using F4 here.

Now. I have used/checked several different values for AAPL,ig-platform-id but here is the one that I am using right now (unmodified):

00 00 16 0A 00 03 03 03 00 00 00 04 00 00 00 01
00 00 F0 00 00 00 00 40 D9 0A 00 00 D9 0A 00 00
00 00 00 00 00 00 00 00 00 00 10 00 02 00 00 00
30 00 00 00 01 05 12 00 04 00 00 00 04 00 00 00
02 04 12 00 00 08 00 00 82 00 00 00 FF 00 01 00
01 00 00 00 40 00 00 00 04 00 00 00 00 00 07 00
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

The reason I highlighted the two values above is simply because I figured out what they are. Note the values of fBacklightFrequency and fBacklightMax in the output (example) below:

IG:: getPlatformID: 1455 AAPL,ig-platform-id = 0x0a160000
IG:: getOSInformation: NNNN [NFB] ————————————————————————
IG:: getOSInformation: NNNN [NFB] PlatformInformation
IG:: getOSInformation: NNNN [NFB] fPipeCount : 3
IG:: getOSInformation: NNNN [NFB] fPortCount : 3
IG:: getOSInformation: NNNN [NFB] fNumFramebuffer : 3
IG:: getOSInformation: NNNN [NFB] fStolenMemorySize : 64 MB
IG:: getOSInformation: NNNN [NFB] fFramebufferMemorySize : 16 MB
IG:: getOSInformation: NNNN [NFB] fFBMemoryCount : 3
IG:: getOSInformation: NNNN [NFB] fCursorBytes : 1572864
IG:: getOSInformation: NNNN [NFB] fBacklightFrequency : 2777
IG:: getOSInformation: NNNN [NFB] fBacklightEnable : 1
IG:: getOSInformation: NNNN [NFB] fBacklightMax :
IG:: getOSInformation: NNNN [NFB] Port[0]: 00000000 / 00000000 / 00000002 / 00000048
IG:: getOSInformation: NNNN [NFB] Port[1]: 00000001 / 00000005 / 00000004 / 00000004
IG:: getOSInformation: NNNN [NFB] Port[2]: 00000002 / 00000004 / 00002048 / 00000130
IG:: getOSInformation: NNNN [NFB] Port[3]: 00000255 / 00000000 / 00000001 / 00000064

Then we convert the decimal value (2777) into a hexadecimal value. Resulting in: 0xAD9. Yes. This shows you how much fun debugging boot flags can be. Oh and let’s go back to CPU power management again.

Native PM without a ssdtPRGen generated SSDT results in:

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

Using Ivy Bridge like P-States (with one extra P-State) results in:

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

Setting Name (APLN, NN) greater than Zero results in:

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

p.s. I have a few more items that I like to discuss here, but I was running out of time. Maybe later. Maybe tomorrow. Don’t forget. I am getting married and we need to do a lot of shopping – need to fill the sailboat with food for our honeymoon trip🙂


Ok. Let’s start with the changed PBlockAddress providing the system I/O address for the processors register block. Each processor can supply a different address, but from now on I’ll be using 0x1810:

Processor (CPUn, 0x01, 0x00001810, 0x06) {}

Here is the one that we have been using with previous generation motherboards:

Processor (CPUn, 0x01, 0x00000410, 0x06) {}

As a reminder. Then I looked at some of the other values I get from my AppleIntelCPUPowerManagementInfo.kext


Not the value I expected and thus I looked in the Intel datasheet. Just to be sure. Nope. Bit-10 (0x400) isn’t set. The lowest three bits are also set to a reserved value (0x05) but it should have been 0x04 to signal C7 package C-State limit. But it isn’t. Which is strange because if you look at this:

MSR_PMG_IO_CAPTURE_BASE….(0xE4) : 0x21814

Here we not only see the new LVL_2 Base Address (0x1814) but also that bit-17 (0x20000) is set. This specifies the encoding value of the maximum C-State code (C7) name to be included when IO read to MWAIT redirection is enabled by bit-10 of MSR_PMG_CST_CONFIG_CONTROL.

The question is why this value isn’t matching up with the other MSR’s but I guess that this is something that we need to figure out later on.

p.s. I have updated ssdtPRGen already, but since it is getting late already… I haven’t pushed it out to the Git repository. Want to verify a couple of things before I do. Not going to happen today. Need my sleep or bad things may happen during our trip…

19 thoughts on “Haswell CPU/iGPU power management with a GA-Z87M-D3H

  1. Hey,
    great work. One tip, the .exe file with which gigabyte packages their BIOS updates is in fact a 7z file with an autounpacker. Just use any 7z supporting software to unpack it.(like StuffIt Expander, free on the store)

    • Thanks. Right. What stupid of me. I just need to install one of my other drives and then I should be ok – I don’t have everything installed on my OS X 10.9 system.

  2. It’s a question I always had…

    If someone uses your same serial number, what happens?

    Besides indicating the model, place and date of manufacture, what other use have the serial?

  3. Sos español? Es más fácil escribirte en español, necesito descargar el AICPUPMI, ¿adónde lo consigo?

    No entiendo mucho inglés pero en el post veo una captura de las frecuencias “Turbo Boost” del procesador en la BIOS. Yo tengo un i5-3570K en una Z77X-UD3H y en la BIOS también aparecen los cuatro núcleos en 38, 38, 37 y 36, ¿eso se deja así o van todos en 38?


  4. I generated a SSDT for my i5-3570K using your ssdtPRGen tool. I’m using Mountain Lion 10.8.4 and I have this PStates: 16 21 28 34 37 38. It’s OK or should there be more?

    When I update to 10.8.5, I need to create a new SSDT or the actual work?

    And how is achieved the AICPUPMI.kext file? I’m not familiar with GitHub.

  5. Muchachos, no entiendo mucho de programacion. Quiero arrancar el 10.8.4 en una plataforma Haswell con un mother Z87X. Hice lo siguiente:
    – Cargue My hack con 10.8.4 a un USB
    – Le cambie el archivo del mach kernel por uno que anda dando vueltas, llamado de 10.8.5 (Cómo saberlo?)
    – Solo obtengo la manzana cngelada o la pantalla en negro.

    Alguna ayuda para el extremo sur del mundo?

    Saludos and go for it!

  6. its kinda lame that I have no idea what your talking about , instead of steps to trying to fix it you’re sharing Dbug info. which is great for you guys who program but I don’t program and I’m just trying to find out how to diagnose my problem =\

    • Sorry, but I do not have the time to write step-by-step guides for unknown issues. I’ll happily leave that up to other people, found in the usual forums. My blog articles are (usually) only meant to help people who know what they are doing. No pun intended.

      • ouch , you said that on purpose =p I ran your script and its spit out an SSDT.aml file, I slapped that puppy in my extra folder and made sure it “Droped SSDT” in my boot file. But when i run terminal and type in = sudo dmesg I get “X86PlatformShim::Start – Failed to send stepper. If you’d like i can copy the “sudo dmesg” info..

      • You only see this message when there is no FrequencyVectors data in the resource plist, the one matching your board-id, or when it won’t be using the data.

  7. Gotcha. Okay, two last questions and I’ll try not to take up any of your time. I have a 4Th Generation I7 4770K 3.5 GHz processor as you can see, using system MacPro 6,1 and Board-Id matching the 6,1. Will the script work with this this board – ID and system definition or do I have to stick with the Mac mini and Macbook Air.

    The settings I used are below:

    majors-mac-pro:~ major$ chmod +x ~/ssdtPRGen.sh
    majors-mac-pro:~ major$ ~/ssdtPRGen.sh -c 2 -f 3900 -t 84 -w 2

    Override value: (-c) CPU type, now using: Haswell!
    Override value: (-f) clock frequency, now using: 3900 MHz!
    Override value: (-t) maximum TDP, now using: 84 Watt!
    Override value: (-w) Ivy Bridge workarounds, now set to: 2!

    System information: Mac OS X 10.9.3 (13D65)
    Brandstring ‘Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz’

    Scope (_PR_) {220 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)
    Generating ssdt.dsl for a ‘MacPro6,1′ with board-id [Mac-F60DEB81FF30ACF6]
    Haswell Core i7-4770K processor [0x306C3] setup [0x0705]
    With a maximum TDP of ’84’ Watt, as specified by argument: -t 84
    Number logical CPU’s: 8 (Core Frequency: 3900 MHz)
    Number of Turbo States: 0
    Number of P-States: 32 (800-3900 MHz)
    Injected C-States for CPU0 (C1,C3,C6)
    Injected C-States for CPU1 (C1,C3,C6)
    Warning: ‘system-type’ may be set improperly (1 instead of 3)

    Intel ACPI Component Architecture
    ASL Optimizing Compiler version 20130117-64 [Jan 19 2013]
    Copyright (c) 2000 – 2013 Intel Corporation

    ASL Input: /Users/xxxx/Desktop/ssdt.dsl – 310 lines, 9476 bytes, 71 keywords
    AML Output: /Users/xxxx/Desktop/ssdt.aml – 2142 bytes, 28 named objects, 43 executable opcodes

    Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

    Do you want to copy /Users/xxxx/Desktop/ssdt.aml to /Extra/ssdt.aml? (y/n)? n
    Do you want to open ssdt.dsl (y/n)? y
    xxxxx-mac-pro:~ xxxx$

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