AppleIntelCPUPowerManagementInfo.kext (MSRDumper successor)

giacomoleopardo · Mar 28, 2013

Pike, I'm going to install 10.8.3 from scratch. As soon as possible I'll post everything you need.

PikeRAlpha · Mar 28, 2013

giacomoleopardo said:
Pike, I'm going to install 10.8.3 from scratch. As soon as possible I'll post everything you need.

Thanks.

toleda · Mar 28, 2013

Well Done.
i7-2600K/H67N, macmini5,1, ssdtPRGen_v5.8
AICPUPMI: CPU P-States [ 16 25 30 34 35 36 37 38 ]

giacomoleopardo · Mar 28, 2013

- EIST enabled in bios
- Fresh ML 10.8.3 install
- chimera 2.0.1
- edited DSDT
- changed SysDef to Macmini 6,2 with Chameleon Wizard
- SSDT generated by your latest script with

Code:

~/ssdtPRGen.sh 4100 40

Code:

sdtPRGen.sh v5.8 Copyright (c) 2013 by Pike R. Alpha
----------------------------------------------------------------
Generating SSDT_PR.dsl for a Macmini6,2 [Mac-F65AE981FFA204ED]
Ivy Bridge Core i7-3770T processor [0x0701] setup
With a maximum TDP of 45 Watt, as specified by Intel
Override value: Max Turbo Frequency, now using: 4100 MHz!
Override value: Max TDP, now using: 40 Watt!
Number logical CPU's: 8 (Core Frequency: 2500 MHz)
Number of Turbo States: 16 (2600-4100 MHz)
Number of P-States: 26 (1600-4100 MHz)
Injected C-States for CPU0 (C1,C3,C6)
Injected C-States for CPU1 (C1,C2,C3)
Warning: Model identifier [Macmini6,2] is missing from: /S*/L*/CoreServices/PlatformSupport.plist

IASL not found. Creating target directory... 
WARNING: Improper use of the sudo command could lead to data loss
or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information.

To proceed, enter your password, or type Ctrl-C to abort.

Password:
Downloading iasl...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1132k  100 1132k    0     0   144k      0  0:00:07  0:00:07 --:--:--  215k
Done.

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

ASL Input:     /Users/gio/Desktop/SSDT_PR.dsl - 262 lines, 8474 bytes, 56 keywords
AML Output:    /Users/gio/Desktop/SSDT_PR.aml - 1620 bytes, 27 named objects, 29 executable opcodes

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

Do you want to copy /Users/gio/Desktop/SSDT_PR.aml to /Extra/SSDT.aml? (y/n)?y
localhost:~ gio$

- Imported edited AppleIntelFramebufferCapri.kext from my previous 10.8.2 install (in order to have the right mappature of physical connectors)
- Lnx2Mac's RealtekRTL81xx.kext from the latest MultiBeast
- no change in AGPM info.plist
- Copied the compiled kext to S/L/E and run the commands you stated in post #1.
This is the result

Code:

Last login: Fri Mar 29 01:02:09 on console
localhost:~ gio$ cat /var/log/system.log | grep "AICPUPMI:"
Mar 29 01:01:04 localhost kernel[0]: AICPUPMI: CPU P-States [ 35 40 ]
Mar 29 01:01:06 localhost kernel[0]: AICPUPMI: CPU P-States [ 35 38 40 ]
Mar 29 01:01:12 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 35 38 40 ]
Mar 29 01:02:00 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 25 ]
Mar 29 01:02:02 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 25 35 ]
Mar 29 01:02:03 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 25 35 40 ]
Mar 29 01:02:06 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 17 25 35 40 ]
Mar 29 01:02:11 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 17 25 35 38 40 ]
Mar 29 01:02:15 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 17 21 25 35 38 40 ]
localhost:~ gio$

- MSRDumper downloaded from here (and attached) with this result

Code:

Mar 28 20:45:29 localhost kernel[0]: MSRDumper CoreMulti(16) 
Mar 28 20:45:29 localhost kernel[0]: MSRDumper PStatesReached: 16 17 21 25 30 31 32 33 34 35 36 37 38 39 40

Attachments:
- DSDT.aml
- IOReg
- MSRDumper.kext
- org.chameleon.Boot.plist
- smbios.plist
- SSDT.aml
- Info.plist (from AppleGraphicsPowerManagement.kext)

PikeRAlpha · Mar 29, 2013

@toleda,

Your P-States are almost identical to mine, but I have an old i5-2500K (using same model identifier). I also noticed that I get one more P-State – nine in total – when push the turbo multipliers to 42.

@giacomoleopardo,

Thanks. I checked the attached MSRDumper.kext and here the output is the same. Except for the top multiplier, which is missing when I use MSRDumper.kext

Why? Well. Let's start with the fact that you have a locked CPU (non K model) and it doesn't seem to accept the 41 multiplier. Lower the top multiplier by one and see if it shows up in the output. MSRDumper.kext normally won't show it, but my AppleIntelCPUPowerManagementInfo.kext should list the top multiplier. If not. Something is wrong. Might be caused by the extra P-State at the top. not sure, but I want to figure out what the problem is. With your help of course.

Note: The non K model CPU's are known to burn out easier/faster so OC'ing can cost you another 300 dollar/euro for a new CPU.

You have EIST enabled in your UEFI/BIOS, but this way you can't be sure about what it is that controls the P-States. It can be the UEFI/BIOS PM module or AppleIntelCPUPowerManagement.kext Or both. My advise is to disable it and to check the output. The question is if this changes anything. Does it?

Now the ultimate test. Make this change in your SSDT under CPU0:

Code:

- Name (APSS, Package (...
+ Name (BUF0, Package (...
+ Name (APSS, Zero)

The idea is to rename the current APSS object into BUF0 and to add a new one. This way all CPU's use Zero instead of a package list. Works fine here, be it with a different output. Enables me to OC without re-generating a new SSDT. Just give it a try and let me know if that changes the output.

But the most important thing is this; Having more P-States isn't necessarily better. A better/equal spread of frequencies is far more important. Not to mention that I still think that the output of MSRDumper.kext is somehow flawed (not confirm Intel specifications).

Thank you for testing this!

giacomoleopardo · Mar 29, 2013

That's a lot of interesting info, here! Give me a few days to check and test: I'm out of town for Easter holidays, and can't use remote. Asap we'll figure out all your (mine) doubts! Meanwhile, thanks for your contribution to PM: your job is outstanding!

sharrken · Mar 29, 2013

i5-3570k, ssdtPRgen 5.8, on an Asrock Z77E-ITX.

SSDT generation run as:

Code:

~/ssdtPRGen.sh 3570k 4500 90

Result:

Code:

Mar 29 12:08:47 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 45 ]
Mar 29 12:08:59 Baldwin kernel[0]: AICPUPMI: CPU P-States [ 16 34 45 ]
Mar 29 12:09:02 Baldwin kernel[0]: AICPUPMI: CPU P-States [ 16 34 40 45 ]
Mar 29 12:09:04 Baldwin kernel[0]: AICPUPMI: CPU P-States [ 16 21 34 40 45 ]
Mar 29 12:09:05 Baldwin kernel[0]: AICPUPMI: CPU P-States [ 16 21 28 34 40 45 ]

Which corresponds to MSRDumper:

Code:

Mar 29 12:09:38 Baldwin kernel[0]: MSRDumper PStatesReached: 16 21 28 34 40 45

Have tested with both EIST enabled and disabled, gives the same results both times. Will test with the BUF0 edit next and update with results, I don't really know if that is relevant to my setup though. Any more tests you want doing (running with other ssdtPRgen configs?) would be happy to help.

edit: applied BUF0 edit to my SSDT. Had to place BUF0 last, and then put APSS back above it or MaciASL gave a compiler error, presumably because Package (...) has to come last in the list? Ended up as follows:

Code:

Scope (\_PR.CPU0)
{
    Name (APLF, 0x08)
    Name (APSN, 0x0C)
    Name (APSS, Zero)
    Name (BUF0, Package (0x27)

This resulted in me losing all PStates save min and max:

Code:

Mar 29 12:39:02 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 45 ]

This concurred with my results from HWSensors and from MSRDumper.

In addition, X86Platform Plugin returned the PState table not found error at start. Increased overclock to 4600Mhz in UEFI setup, without regenerating SSDT, and AICPUPMI registered it:

Code:

Mar 29 12:39:02 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 46 ]

This did not return the usual fixed 800Mhz state when I have no SSDT, it seemed to work just as before with the BUF0 edit.

I also did another test, as I'm not really sure that I did the SSDT edit right in the first place - I swapped BUF0 and APSS back around (so BUF0 now points to Zero), and then changed all instances of APSS to BUF0 outside of CPU0 - trying to get it so that all PStates for CPU1-3 should just point to zero. This had a rather interesting result - during the login process, AICPUPMI registered

Code:

Mar 29 13:11:46 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 46 ]

but after boot, I was stuck at the 8x multiplier the whole time. Checking the log, MSRdumper has registered an erratic jump to a 16x multiplier a few times (33 times over a half hour period, relatively evenly distributed). This jump is also visible in HWSensors, but I could not get it to happen via stress or anything else, appeared to be totally random. I don't really know if this is atall helpful, as my edit is probably completely wrong and doesn't really do anything. But it did seem a bit odd that AICPUPMI registered 16 and 46 even though they have not actually loaded successfully though, as this could create problems for people thinking an SSDT is working when in fact it is not.

PikeRAlpha · Mar 30, 2013

@sharrken,

Thank you for testing all this. What I can tell you is that the reported P-States are ok. With EIST enabled and disabled. Again. All fine.

The first mods to the SSDT also seem to have the same effect as what I had here. I'm uncertain about the modifications you made the second time, but let's just wait for another brave soul to reproduce all this.

Gettings the error is of course expected. This after all is a test to get to the bottom of things.

Francis · Mar 30, 2013

PikeRAlpha said:
You have EIST enabled in your UEFI/BIOS, but this way you can't be sure about what it is that controls the P-States. It can be the UEFI/BIOS PM module or AppleIntelCPUPowerManagement.kext Or both. My advise is to disable it and to check the output. The question is if this changes anything. Does it?

Code:
Now the ultimate test. Make this change in your SSDT under CPU0:

Code:

- Name (APSS, Package (... + Name (BUF0, Package (... + Name (APSS, Zero)

The idea is to rename the current APSS object into BUF0 and to add a new one. This way all CPU's use Zero instead of a package list. Works fine here, be it with a different output. Enables me to OC without re-generating a new SSDT. Just give it a try and let me know if that changes the output.
Thank you for testing this!

Configuration:
Proc: Xeon-E3 so no OC, freq = 16-33 (+2344 turbo)
SSDT generated with 5,7 script version
Board-ID: iMac13,1
Bios: EIST disabled, turbo enabled
Chameleon : DropSSDT=yes, does not Generate PStates or CStates
FakeSMC: 5.1.45 (using plugins actually, will try without any plugin).

I consistently get this result, with standard SSDT

Code:

Mar 28 07:57:01 xeon-e3 kernel[0]: AICPUPMI: CPU P-States [ 16 33 35 ]
Mar 28 07:57:02 xeon-e3 kernel[0]: AICPUPMI: CPU P-States [ 16 33 35 36 ]
Mar 28 07:57:02 xeon-e3 kernel[0]: AICPUPMI: CPU P-States [ 16 33 35 36 37 ]

So no PStates between min and topfreq + turbo. I got some more as Macmini6,2 but prefer running as iMac as I use a discrete graphic card.

After having appied the APSS/BUF0 edit to SSDT, I get same result for AICPUPMI: CPU P-States [ 16 33 35 36 37 ]
but a lot of new errors (have not seen them with standard ssdt) in dmesg, extracted from boot dmesg (I have left out unrelevant parts):

Code:

Kernel is LP64
...
AICPUPMI: CPU P-States [ 33 ]
AICPUPMI: CPU P-States [ 16 33 ]
...
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
DSMOS has arrived
[IOBluetoothHCIController][start] -- completed
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
X86PlatformPlugin::getCPUPStates - acpiPSArrayObj is not an valid OSArray
X86PlatformPlugin::publishACPIStates - Failed to get CPU P States!
X86PlatformPlugin::setRingTable - No ring table found!
X86PlatformPlugin::configResourceHandler - Failed to set ring table!
X86PlatformShim::sendPStates - Failed to get the first package of pstates!
X86PlatformShim::start - Failed to send PStates
[AGPM Controller] build GPUDict by Vendor10deDevice0fc6
AICPUPMI: CPU P-States [ 16 33 35 ]
X86PlatformPlugin::setPLimitRange - Failed to get the first package of pstates!
macx_swapon SUCCESS
Sandbox: sandboxd(116) deny mach-lookup com.apple.coresymbolicationd
AICPUPMI: CPU P-States [ 16 33 35 37 ]
AICPUPMI: CPU P-States [ 16 33 35 36 37 ]
...
Sandbox: sandboxd(250) deny mach-lookup com.apple.coresymbolicationd
ast_pending=0xffffff80002a74b0
cpu_interrupt=0xffffff80002bea40

I will try disably FakeSMC plugins and CalDigit USB3 kext.

ok_tod · Apr 1, 2013

AICPUPMI

Code:

localhost:~ mac$ cat /var/log/system.log | grep "AICPUPMI:"
Apr  1 12:04:49 localhost kernel[0]: AICPUPMI: CPU P-States [ 36 38 ]
Apr  1 12:04:49 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 36 38 ]
Apr  1 12:05:00 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 21 36 38 ]
Apr  1 12:05:04 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 21 36 37 38 ]
Apr  1 12:05:10 localhost kernel[0]: AICPUPMI: CPU P-States [ 16 21 28 36 37 38 ]
Apr  1 12:05:43 macmini-902b34516098 kernel[0]: AICPUPMI: CPU P-States [ 16 21 28 34 36 37 38 ]

boot-RevoBoot v1.5.38

AICPM

Code:

localhost:~ mac$ cat /var/log/system.log | grep "AICPM"
Apr  1 12:04:51 localhost kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
Apr  1 12:07:55 localhost kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
Apr  2 08:37:33 localhost kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
Apr  2 08:54:30 localhost kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
Apr  2 08:58:10 localhost kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
Apr  2 09:14:17 localhost kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0

Search

AppleIntelCPUPowerManagementInfo.kext (MSRDumper successor)

giacomoleopardo

PikeRAlpha

toleda

Moderator

giacomoleopardo

Attachments

PikeRAlpha

giacomoleopardo

sharrken

PikeRAlpha

Francis

ok_tod

Forum

Guides

Downloads