Core i7-3770K cannot get SpeedStep/PM on 10.8.5 or 10.9.2 (latest scripts) about ssdtprgen.sh HOT 25 OPEN

Running ./ssdtPRGen.sh -w will add the top and bottom P-States, but your CPU it won't use any frequency below 1600 MHz. This was the default for older versions of ssdtPRGen.sh, for OS X versions without xcpm support. The latter made it a little more complicated. Anyway. You are not using XCPM, aka mach_kernel power management, and looking at the filename "ssdt-with-w3-param-yes-working.dsl" -w 3 seems to work so what is the problem? It only works with the HD4000? Not with a discrete GPU?

By the way. What Mac model and board-id are you using?

from ssdtprgen.sh.

Hi mate, I apologize for the lack of such info, it was late at night :-) My questions here are not to complain of course, merely to understand and learn some things that, for me, didn't make sense.

Using Core i7-3770K on Gigabyte GA-Z77N-WIFI (not-overclocked) set as Macmini6,2 with board ID Mac-F65AE981FFA204ED. Apparently, also iMac13,1 (with Mac-00BE6ED71E35EB86) is compatible but I read everywhere that Macmini6,2 has better results for this CPU.

Indeed with -w 3 flag, the resulting SSDT works properly, so my question was why adding this workaround top/bottom in code works? The OS needs these values to be present, even if never achieved? e.g. 800MHz for CPU! Especially the top one at 3901MHz is an interesting entry.

But when generating SSDT without flags, as I mentioned, and if DropSSDT=Yes then the desktop loads at fixed 800MHz which wasn't expected behavior...

I have an update:
In another forum, I discovered that 10.8.5 (and later) kernel introduced indeed XCPM management and with a simple -xcpm flag in org.chameleon.Boot.plist the issue is resolved in both 10.8.5 and 10.9.2 and now 10.9.3. Turbo boost is well recognized and stepping works, Geekbench results are very good too. This was without using any SSDT.aml generated, and without Dropping SSDT flag in Chameleon. Very interesting.

The only thing I get is an error in Mavericks about unknown CPU ID, I guess expected, right?

What is your advice? DropSSDT=Yes and using a normal SSDT (no workarounds) with XCPM flag in kernel? (to introduce that "plugin-type" part in the code?)

I re-generated SSDT with the script v13.5 now and getting same output with either plain or W=3 flag, as your script seems to properly detect XCPM and ignoring the flag:

ssdtPRGen.sh v0.9 Copyright (c) 2011-2012 by † RevoGirl
v6.6 Copyright (c) 2013 by † Jeroen

v13.5 Copyright (c) 2013-2014 by Pike R. Alpha

System information: Mac OS X 10.8.5 (12F45)
Brandstring 'Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz'

Scope (PR) {220 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)
Generating ssdt.dsl for a 'Macmini6,2' with board-id [Mac-F65AE981FFA204ED]
Ivy Bridge Core i7-3770K processor [0x306A9] setup [0x0703]
With a maximum TDP of 77 Watt, as specified by Intel
Number logical CPU's: 8 (Core Frequency: 3500 MHz)
Number of Turbo States: 4 (3600-3900 MHz)
Number of P-States: 24 (1600-3900 MHz)
Injected C-States for CPU0 (C1,C3,C6)
Injected C-States for CPU1 (C1,C2,C3)

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

ASL Input: /Users/Konsti/Desktop/ssdt.dsl - 303 lines, 8860 bytes, 71 keywords
AML Output: /Users/Konsti/Desktop/ssdt.aml - 1993 bytes, 28 named objects, 43 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

(sorry I tried to find the [code] tag but don't know how, I made them as quoted) and the one generated with -w 3 is here, for your reference:

ssdtPRGen.sh v0.9 Copyright (c) 2011-2012 by † RevoGirl
v6.6 Copyright (c) 2013 by † Jeroen

v13.5 Copyright (c) 2013-2014 by Pike R. Alpha

Override value: (-w) Ivy Bridge workarounds, now set to: 3!

System information: Mac OS X 10.8.5 (12F45)
Brandstring 'Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz'

Scope (PR) {220 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)
Generating ssdt.dsl for a 'Macmini6,2' with board-id [Mac-F65AE981FFA204ED]
Ivy Bridge Core i7-3770K processor [0x306A9] setup [0x0703]
With a maximum TDP of 77 Watt, as specified by Intel
Number logical CPU's: 8 (Core Frequency: 3500 MHz)
Number of Turbo States: 4 (3600-3900 MHz)
Number of P-States: 24 (1600-3900 MHz)

XCPM mode detected (Ivy Bridge workarounds disabled)

Injected C-States for CPU0 (C1,C3,C6)
Injected C-States for CPU1 (C1,C2,C3)

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

ASL Input: /Users/Konsti/Desktop/ssdt.dsl - 303 lines, 8860 bytes, 71 keywords
AML Output: /Users/Konsti/Desktop/ssdt.aml - 1993 bytes, 28 named objects, 43 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations

from ssdtprgen.sh.

Use this script https://github.com/Piker-Alpha/debugMachKernel.sh
to enable debug output (see /var/log/system.log) and add: "debug=0x12a ioppf=0xff"
under 'Kernel Flags' in com.apple.Boot.plist to verify if everything is working without errors (there should be none).

from ssdtprgen.sh.

Thanks for your input, will do ASAP. Just to update you:
When using the -xcpm flag in booting, with the newly created SSDT.aml (without the bug/workaround) and DropSSDT=Yes, I am getting many errors on both 10.8.5 and 10.9.3 which I'd like you to comment, if you have time. In the meantime, I will do what you suggested with the kernel output:

5/18/14 11:39:32.000 AM kernel[0]: XCPM: registered
5/18/14 11:39:33.000 AM kernel[0]: SMC::smcInitHelper ERROR: MMIO regMap == NULL - fall back to old SMC mode
5/18/14 11:39:33.000 AM kernel[0]: com_intel_driver_EnergyDriver[0xffffff8011f57c00]::start(0xffffff8010e95c00)
5/18/14 11:39:33.000 AM kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
5/18/14 11:39:33.000 AM kernel[0]: X86PlatformPlugin::configResourceHandler - Failed to set ring table!
5/18/14 11:39:34.000 AM kernel[0]: IOPPF: XCPM mode
5/18/14 11:39:34.000 AM kernel[0]: XCPM: P-state table mismatch (error:0x11)
5/18/14 11:39:34.000 AM kernel[0]: X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
5/18/14 11:39:34.000 AM kernel[0]: X86PlatformShim::start - Failed to send PStates
5/18/14 11:39:34.000 AM kernel[0]: X86PlatformShim::initializePMInfo - Failed to send stepper
5/18/14 11:41:05.000 AM kernel[0]: considerRebuildOfPrelinkedKernel com.apple.driver.X86PlatformPlugin triggered rebuild

If booting without SSDT.aml and DropSSDT=No but using only -xcpm flag, all is perfect except the warning of the CPU ID not being recognized.

from ssdtprgen.sh.

Let's stick to one power management feature at a time. Preferable the non-xcpm one so please remove the -xcpm flag (for now) and without this flag you are using the AppleIntelCPUPowerManagement.kext which used to work with Sandy Bridge and Ivy Bridge processors.

I also need to know if you are using a patched version of the kext, or that you are using the factory/original one. Which in my opinion is preferred.

In short. Run ./ssdtPRGen.sh -w 3 -x 0 and reboot without the -xcpm flag.
The -x 0 arguments was added to disable xcpm, which may still be active at the time you are running the script. Then tell me what errors you get. Note that the SMC/energy drivers messages are unrelated and thus can be ignored.

p.s. Please. Do not change your SMBIOS data, because that adds complexity. Something I don't have time for right now.

from ssdtprgen.sh.

OK mate, did as requested. Nothing is patched at all, especially AppleIntelCPUPowerManagement.kext is vanilla. Also, always using Macmini6,2 as I also don't expect to experiment with smbios.plist as you said.

With latest script v13.5, compiled -w 3 -x 0 and rebooted without -xcpm, but with DropSSDT=Yes. It works as expected, Turbo goes to 3.90GHz and GeekBench produces similar results (10.8.5). The AppleIntelCPUPowerManagement.kext is loaded when checking the kexts on Terminal. I get these messages to Console (with "kernel" filter):

5/18/14 3:57:27.000 PM kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 4444
5/18/14 3:57:27.000 PM kernel[0]: AppleIntelCPUPowerManagement: (built 13:50:43 Sep 29 2013) initialization complete
5/18/14 3:57:27.000 PM kernel[0]: AppleIntelCPUPowerManagementClient: ready
5/18/14 3:57:27.000 PM kernel[0]: BTCOEXIST off
5/18/14 3:57:28.000 PM kernel[0]: com_intel_driver_EnergyDriver[0xffffff8011eafb00]::start(0xffffff8010dd8c00)
5/18/14 3:57:28.000 PM kernel[0]: SMC::smcInitHelper ERROR: MMIO regMap == NULL - fall back to old SMC mode
5/18/14 3:57:28.000 PM kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
5/18/14 3:57:28.000 PM kernel[0]: X86PlatformPlugin::configResourceHandler - Failed to set ring table!
5/18/14 3:57:29.000 PM kernel[0]: IOPPF: AppleIntelCPUPowerManagement mode

Minimum CPU is 1600MHz and maximum (Turbo) is properly reaching 3900MHz.

Now, if I replace SSDT.aml without changing anything else at all, with the one NOT including the bug fix and those added workarounds for Ivy Bridge, the OS boots and clock is locked at 800MHz which is totally wrong. Can't even imagine why it goes to 800MHz to begin with :-) Even GeekBench that's pushing CPUs isn't changing the clocks (verified via Intel Power Gadget too). Console errors same as above. The AppleIntelCPUPowerManagement.kext is loaded when checking the kexts on Terminal. Weird!

from ssdtprgen.sh.

The only two items that jump out are:

"AppleIntelCPUPowerManagement: Turbo Ratios 4444"
Meaning that all Turbo states are set to 39 in your BIOS. You may want to change this to say: 36, 37, 38 and 39

"X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0"
I don't know why, but it may be related to the system-type. Are you using 1 for desktop or a 2 for mobile in your SMBIOS settings?

from ssdtprgen.sh.

Hi mate, in the org.chameleon.Boot file, the "SystemType" key is of course 1 for desktop (Mac Mini). The BIOS was reverted to "Optimized Defaults" and the Frequency screen/tab shows no setting for Turbo states, to be honest. I read on TonyMacX86 forums that with default BIOS settings this board works fine. Please remember it's Core i7-3770K the K-variant…

There's a BIOS page for setting "Advanced CPU Core features". It has Turbo Ratio 39 for 1 active core, 39 for 2 cores, 38 for 3 cores, 37 for 4 active cores but all set to "Auto". Should I change that to forced values?

OK just did -- rebooted with forced (same) values instead of auto-setting. Other CPU parameters are now "Enabled" instead of "Auto". Now I get "Turbo Ratios 2344" in boot log. GeekBench shows lower results now (as 4 cores go to max. 3700MHz obviously). Not good...

Nevertheless, I am still getting that other errors :-(

5/18/14 5:16:44.000 PM kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
5/18/14 5:16:44.000 PM kernel[0]: X86PlatformPlugin::configResourceHandler - Failed to set ring table!

NOTE: Obviously with the -xcpm there is no "Turbo Ratios" entry in Console from AppleIntelCPUPowerManagement, as I checked in earlier boot-logs, nor the X86PlatformPlugin errors.

from ssdtprgen.sh.

Sure. Use whatever turbo settings you want, but that's not how Apple is setting them. Anyway. You said:

"When using the -xcpm flag in booting, with the newly created SSDT.aml (without the bug/workaround) and DropSSDT=Yes, I am getting many errors on both 10.8.5 and 10.9.3"

But now you say there are no X86PlatformPlugin errors with -xcpm in com.apple.Boot.plist? Surely you understand the confusion here?

Update:
The X86PlatformPlugin::setRingTable related errors can be ignored – also seen on genuine Mac models!

Now you can add -xcpm under "Kernel Flags" and run: ./ssdtPRGen.sh -x 1 to see what that brings.

from ssdtprgen.sh.

Hi Pike, thank you again for spending time to investigate this issue. Sorry if it was not clear. Allow me to explain the 3 scenarios (with vanilla kexts, same SMBIOS etc.):

1. Load only with -xcpm flag, no SSDT.aml present in /Extra/ and no BIOS tweaking. Results are good, only issue is the "unknown CPU" error in 10.8.5 with SpeedStep and Turbo working.
2. Load with DropSSDT=Yes, SSDT.aml generated with workaround -w3 and no -xcpm flag. SpeedStep and Turbo working, with the errors mentioned above. BIOS settings not touched.
3. Load with DropSSDT=Yes, SSDT.aml generated without workarounds (i.e. using a "purer" SSDT) and with -xcpm flag, still getting these "X86PlatformPlugin" errors. BIOS settings not touched. Clock stuck at 800MHz!

Let me know if it's useful to create a text file with the 3 different kernel logs, I'd like to ease your life as much as possible :-)

EDIT: Missed your update, will check and report back. Many many thanks again.

from ssdtprgen.sh.

Loading with only -xcpm and without SSDT.aml at all, running ssdtPRGen.sh -x 1 produces the following:

ssdtPRGen.sh v0.9 Copyright (c) 2011-2012 by † RevoGirl
v6.6 Copyright (c) 2013 by † Jeroen

v13.5 Copyright (c) 2013-2014 by Pike R. Alpha

Override value: (-x) XCPM mode, now set to: 1!

System information: Mac OS X 10.8.5 (12F45)
Brandstring 'Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz'

Scope (PR) {220 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)
Generating ssdt.dsl for a 'Macmini6,2' with board-id [Mac-F65AE981FFA204ED]
Ivy Bridge Core i7-3770K processor [0x306A9] setup [0x0703]
With a maximum TDP of 77 Watt, as specified by Intel
Number logical CPU's: 8 (Core Frequency: 3500 MHz)
Number of Turbo States: 4 (3600-3900 MHz)
Number of P-States: 24 (1600-3900 MHz)
Injected C-States for CPU0 (C1,C3,C6)
Injected C-States for CPU1 (C1,C2,C3)

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

ASL Input: /Users/Konsti/Desktop/ssdt.dsl - 303 lines, 8860 bytes, 71 keywords
AML Output: /Users/Konsti/Desktop/ssdt.aml - 1993 bytes, 28 named objects, 43 executable opcodes

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

Text-comparing the resulting SSDT.DSL with previously generated, shows no difference at all with the "cleaner" SSDT i.e. no workarounds inside, nor any value changes in C/P-Steps…

I have compiled the log for 4 scenarios, here:

1. Load only with -xcpm flag, no SSDT.aml present in /Extra/ and no BIOS tweaking. Results are good, only issue is the "unknown CPU" error in 10.8.5 with SpeedStep and Turbo working.
2. Load with DropSSDT=Yes, SSDT.aml generated with workaround -w 3 and no -xcpm boot kernel flag. SpeedStep and Turbo working, with the errors mentioned above. BIOS settings not touched.
3. Load with DropSSDT=Yes, SSDT.aml generated without workarounds (i.e. using a "purer" SSDT) and with -xcpm flag, still getting these "X86PlatformPlugin" errors. BIOS settings not touched. Clock stuck at 800MHz!
4. Load with DropSSDT=Yes, SSDT.aml generated including workarounds and with -xcpm flag. Getting major other errors, of P-state table mismatch (error:0x12), Failed to send PStates, Failed to send stepper, etc.

Logs uploaded here, many thanks: http://pastebin.com/YtJBhXVX

from ssdtprgen.sh.

1. This must be broken because then the plugin-type property won't be there under CPU0.
2. This one looks fine to me.
3. Expected result.
4. XCPM is different and may require some testing on your end:

a. First try -x 1 only.

b. If -x doesn't work then try -w N -x 0 (where N is 1, or 2).

c. If that still doesn't work then use -w 3 -x 0 and remove these:

        Package (0x06) { 0x044C,     Zero, 0x0A, 0x0A, 0x0B00, 0x0B00 },
        Package (0x06) { 0x03E8,     Zero, 0x0A, 0x0A, 0x0A00, 0x0A00 },
        Package (0x06) { 0x0384,     Zero, 0x0A, 0x0A, 0x0900, 0x0900 },
        Package (0x06) { 0x0320,     Zero, 0x0A, 0x0A, 0x0800, 0x0800 }

Now fix the package length from 0x21 to 0x1D and change Name (APLF, 0x08) to Name (APLF, 0x04) Compile and reboot and report back (thanks).

from ssdtprgen.sh.

OK here are my results (on 10.8.5 as it's my first boot partition):

1. Indeed, without SSDT.aml at all and -xcpm flag, there's no "plugin-type" property injected. Is there a way to introduce it in my DSDT.aml?
2. Yes, looks fine -- I just need to understand later why these crazy workaround are needed :-)
3. You expected result to go 800MHz? Interesting. Where is this frequency coming from…?
4. Attempts with -xcpm kernel flag and DropSSDT=Yes:

a) generated with -x 1 only: still getting errors:

PM kernel[0]: XCPM: registered
PM kernel[0]: XCPM: P-state table mismatch (error:0x12)
PM kernel[0]: X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x12
PM kernel[0]: X86PlatformShim::start - Failed to send PStates
PM kernel[0]: X86PlatformShim::initializePMInfo - Failed to send stepper

b) generated with -w 1 -x 0: Same errors as a)

c) generated with -w 2 -x 0: only stepper; no error on PStates found.

PM kernel[0]: X86PlatformShim::initializePMInfo - Failed to send stepper

d) Generated with -w 3 -x 0 and removed bottom 4 entries, fixed APLF and recompiled:

Same errors as a) except the value:

PM kernel[0]: XCPM: P-state table mismatch (error:0x13)

What does APLF value reflect?

NOTE: I am totally ignoring the errors below, didn't expect you to say they appear on real Macs!

PM kernel[0]: X86PlatformPlugin::setRingTable - AICPM failed to load ring table with status 0x0: Get=0, Load=0, Install=0
PM kernel[0]: X86PlatformPlugin::configResourceHandler - Failed to set ring table!

I hope I gave you a better idea? Many thanks, mate.

from ssdtprgen.sh.

I have to be quick so the only thing I need to know is if -w 3 -x 0 worked or not.
The rest will be answered later today. Adding stuff when I find the time for it.

1. You can use this under CPU0 (see Processor declarations in your DSDT.dsl):

   Method (_DSM, 4, NotSerialized)
   {
       Store ("Method CPU0._DSM Called", Debug)
   
       If (LEqual (Arg2, Zero))
       {
           Return (Buffer (One)
           {
               0x03
           })
       }
   
       Return (Package (0x02)
       {
           "plugin-type",
           One
       })
   }
   

2. Use this when -xcpm won't work for your setup.

3. Without the Ivy Bridge workaround(s) it will step down to 800 MHz (locked) and nobody ever figured out why.

4. -w 2 -x 0 is the way to go because now the P-State errors are gone. The one error left is one caused by the used stepContextDict in the plist and thus I would like to suggest that you backup your copy of Mac-F65AE981FFA204ED.plist and then try one of the MacBook Air's (Mac-66F35F19FE2A0D05.plist or Mac-2E6FAB96566FE58C.plist). That should take care of the error – though I am not sure. Sorry. Long time ago I even had an Ivy Bridge processor.

APLF should point to the lowest possible frequency for your CPU (1600 MHz)

from ssdtprgen.sh.

Hello again PikerAlpha, sorry for my absence, too busy at work and not time to experiment and fix. Anyway, I formatted and re-installed 10.9.3; I must have rebooted 100 times (thank God for SSD) and I've been battling all this time to make Clover work (readying myself for Yosemite) but I am getting different SSDT results to Chameleon!

With BIOS defaults (i.e. CPU Core features as Auto), i7-3770K, OS X 10.9.3 now and MacMini6,2 and DropSSDT=Yes:

a) Chameleon without -xcmp
The value of the script that works is only -w3 -x0 it seems. Only errors in bootlog:

SMC::smcInitHelper ERROR: MMIO regMap == NULL - fall back to old SMC mode
X86PlatformPlugin::setRingTable - AICPM failed […] with status 0x0: Get=0, Load=0, Install=0
X86PlatformPlugin::configResourceHandler - Failed to set ring table!

Values -w1 or -w2 with -x0 produces the known 800MHz lock. So no point investigating further. Same stands for using your script without any parameters, system locks at 800MHz.

b) Chameleon with -xcmp but DropSSDT=No

XCPM: registered
ACPI_SMC_PlatformPlugin::start - waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x3a -- power management may be incomplete or unsupported

Using the DSDT fix in CPU0 that you suggested, produces unexpected errors. Is it because of the CPU model? Anything to tell the system it's a compatible i7-3770 CPU? There's no XCPM registered line:

X86PlatformPlugin::publishACPIStates - Failed to get max non-turbo PState. Set max non-turbo PState to default value 1
X86PlatformPlugin::setRingTable - AICPM failed […] status 0x0: Get=0, Load=0, Install=0
X86PlatformPlugin::configResourceHandler - Failed to set ring table!
IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x17)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x17
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

Back to working DSDT without the CPU0 fix, obviously.

c) Chameleon with -xcmp and DropSSDT=Yes now:

Value -w 3 -x 1 curiously produces errors:

XCPM: registered
X86PlatformPlugin::setRingTable - AICPM failed […] status 0x0: Get=0, Load=0, Install=0
X86PlatformPlugin::configResourceHandler - Failed to set ring table!
IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x12)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x12
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

Value -w 2 -x 1 produces less:

XCPM: registered
X86PlatformPlugin::setRingTable - AICPM failed […] with status 0x0: Get=0, Load=0, Install=0
X86PlatformPlugin::configResourceHandler - Failed to set ring table!
IOPPF: XCPM mode
X86PlatformShim::start - Failed to send stepper

Value -w 1 -x 1 produces:

XCPM: registered
X86PlatformPlugin::setRingTable - AICPM failed […] with status 0x0: Get=0, Load=0, Install=0
X86PlatformPlugin::configResourceHandler - Failed to set ring table!
IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x13)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x13
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

Suggestions? Modify the Mac hardware profile as you wrote?

1. Please notice the different pmCPUControl values returned each time; don't know what they mean.
2. Ideally we should start using -xcmp as we don't know what OS X 10.10 will bring.
3. Why is Clover so different in behavior than Chameleon, any idea? With Clover I can't get any combination to work properly! With or without -xcpm!

Many thanks, hope you have a clearer picture now… that was a log of debugging ;-)

UPDATE:

Saw also your post (http://www.tonymacx86.com/mountain-lion-desktop-support/86807-ml-native-ivy-bridge-cpu-gpu-power-management.html) and replaced Mac-F65AE981FFA204ED.plist with the ones for MacBookPro10,1 etc. and can't shake off that "Failed to send stepper" error :-(

Also, changing SMBIOS to Mac13,2 that has i7-3770 CPU, causes kernel panics (SSDT not dropped and with -xcpm as flag). Without -xcpm, it boots but no Turbo mode and still unknown CPU error...

from ssdtprgen.sh.

This "X86PlatformShim::start - Failed to send stepper" can be stopped by adding a boot argument (-xcpm_ignore_fv). Thanks to techblowfish for the friendly reminder.

from ssdtprgen.sh.

@mackonsti I have the same CPU as you, just a different motherboard. I must say that the errors you are getting are far in excess of those i came across when setting up my system. My incline is that these errors maybe related to Chameleon/Chimera and perhaps whatever version you may be running. I do not think that Piker's script is the one causing all these errors but I could be wrong. I'd advise you setup a pure UEFI environment in your BIOS and using Clover. I believe this way we can welter down these logs to focus on the important ones.

from ssdtprgen.sh.

Hello to both of you, Piker, Techblowfish, thanks for your help. As I mentioned earlier to Piker, Clover has a very different behaviour to Chameleon. Using both latest versions. As I am trying to iron out issues, I used Chameleon that I know well; was battling Clover until recently. Allow me to come back to you this weekend with findings on Clover and Core i7-3770K. It's not Piker's script most likely, just that I am doing all reboots with different scenarios, so I can help Piker too, in his excellent work. Thanks again.

@techblowfish do you use a similar mainboard, with same Z77 chipset or H77?
Do you have any suggestions for Clover parameters, to begin with?

@Piker-Alpha do you think that -using xcpm_ignore_fv flag, will kill the error but still Speedstepping will work properly? You seem to have investigated the kernel, recently, hence my question. Should I use that special kext you have on your blog, to check the P/C states debug output?

from ssdtprgen.sh.

I use a ASUS P8Z77-v pro. I would advise you to use a DSDT and an SSDT with Clover. If you need to have a look at my config.plist i can post it here.

My system worked fine even with that error. This is because the IvyBridge CPUs do not use frequency vectors anyway. The (-xcpm_ignore_fv) flag explicitly informs the Kernel not to try to load any frequency vectors from a file.

from ssdtprgen.sh.

Hello guys, here are my results. Mavericks 10.9.3 with Clover_v2k_2703 installed on external USB stick.

Settings Gigabyte GA-Z77N-WIFI:

Load Optimized Defaults.
In Peripherals tab, set xHCI Mode to "Enabled".
In BIOS Features tab, set Intel Virtualization Technology to to "Enabled".
In M.I.T. tab, set Advanced Memory Settings of Extreme Memory Profile (X.M.P.) to "Profile1".
In BIOS Features tab, set OS Type to "Windows 8 HWQL" and CSM Support to "Never".

Settings in Clover:

ACPI: Nothing checked, only DSDT.aml name entered
Boot: -v darkwake=0 -xcpm + XMPDetection and Secure (checked)
Devices: Nothing ("Add Clock ID" unchecked, dunno if needs to)
GUI scan Entries + Tool + Legacy
No graphics injection (got both Intel+NVidia covered in edited DSDT.aml)
Kernel: AppleRTC + Asus AICPUPM checked
SMBIOS: set as MacMini6,2
System: Inject System ID checked

I get in boot log with Turbo working (up to 3.9GHz) and Geekbench (x64) at 14810:

XCPM: registered
X86PlatformPlugin::setRingTable - AICPM failed […] with status 0x0: Get=0, Load=0, Install=0
X86PlatformPlugin::configResourceHandler - Failed to set ring table!
IOPPF: XCPM mode
X86PlatformShim::start - Failed to send stepper

Interesting fact: Even if I don't have DropOem checked, I have an SSDT.aml in the "patched" directory hence the lack of the errors below (which means it's been read):

ACPI_SMC_PlatformPlugin::start - waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out
WARNING: IOPlatformPluginUtil : getCPUIDInfo: this is an unknown CPU model 0x3a -- power management may be incomplete or unsupported

Adding your extra flag i.e. -v darkwake=0 -xcpm -xcpm_ignore_fv results to same "failed to send to stepper" error being present. It's not clear to me if we include both or either xcpm flags :-)

If I remove -xcpm completely, the boot process freezes and I can't get to desktop (running verbose boot at the moment). I think it freezes before the part where the OS tries to determine CPU power management etc. and USB devices freeze too. Any ideas/suggestions why? Could it be Clover?

With -xcpm removed from kernel flags, even setting DropOem=Yes and having an SSDT.aml in "ACPI/patched" still can't boot… it's crazy. Changed to iMac13,2 but same result.

@techblowfish can you please share your Clover config.plist in a site like pastebin.com? Do you use simple/secure UEFI boot in BIOS? Perhaps also share your SSDT too?

UPDATE: using both -xcpm and -xcpm_ignore_fv causes a new error to appear:

Error - kext com.apple.filesystems.autofs declares a dependency on com.apple.kpi.private. Only Apple kexts may declare a dependency on com.apple.kpi.private.
Can't load kext com.apple.filesystems.autofs - failed to resolve library dependencies.
Kext com.apple.filesystems.autofs failed to load (0xdc00800e).
Failed to load kext com.apple.filesystems.autofs (error 0xdc00800e).

Can you confirm it, guys?

from ssdtprgen.sh.

Here is my config.plist
https://dl.dropboxusercontent.com/u/47308831/config.plist

Please try not use XMP until you have a stable system. So just load optimised defaults like you have done. Also, why not try to install clover on the same hard drive as your OS. Backup first please.

from ssdtprgen.sh.

Thank you @techblowfish for your Clover config.plist, I was able to get my system to a stabler Clover booting condition, but I still get the "stepper" error:

XCPM: registered
X86PlatformPlugin::setRingTable - AICPM failed […] with status 0x0: Get=0, Load=0, Install=0
X86PlatformPlugin::configResourceHandler - Failed to set ring table!
IOPPF: XCPM mode
X86PlatformShim::start - Failed to send stepper

And of course, booting without -xcpm is not working as the system just stops in verbose (I don't have desktop, but seems system loads, can access via SSH from another Mac). I am not aware of any other Clover parameter that will allow to boot without -xcpm? Like dart=0?

Also, I used your DropTables parameters, too, and the SSDT.aml with only the -w 2 parameter fixes (i.e. lower P-State values injected).

Boot flags -xcpm and -xcpm_ignore_fv didn't change anything with respect to the "stepper" error, and disabling CPU features in BIOS as you posted on Piker's blog, didn't help either. Any comment @Piker-Alpha on these two simultaneous flags?

from ssdtprgen.sh.

It seems that your system needs to use a patched kernel in order to be able to use the "-xcpm" and "xcpm_ignore_fv" flags. This is why you are getting kernel panic. So you can try this:
http://www.insanelymac.com/forum/topic/295587-power-management-for-sandyivy-bridgehaswell-cpus/

I have used the Perl script 10.9.1 for 10.9.3 and it works.
Also your graphics card may be related to why you do not see the desktop. I have a GTX 650Ti Boost. So make sure you are using the correct flags in your config.plist for the graphics.

from ssdtprgen.sh.

Hi @techblowfish thank you for your tip, but why would I need to patch the setup/kernel since it does detect -xcmp flag. Just not the other one. So can we use both or either?

Still declaring Macmini6,2 and running 10.9.3. Removed GFX0 (NVidia GeForce GT 610) and used DSDT for Intel HD Graphics (as there are 2 SystemMemory settings in DSDT that crash computer if not changed). Anyway, for testing, I did patch the kernel and to be honest, the error is still there. Patched, cleared kextcache, rebooted:

a) Flag -xcpm still has "Failed to send stepper" error.
b) Flag alone -xcpm_ignore_fv locks clock at 800MHz!
c) Flag added -xcpm_ignore_fv and patched kernel, I get panic first time. Upon re-reboot, the error "Failed to send stepper" is there :-(

With patched kernel, which SSDT do you use? With fixes or plain? If you're interested, here is my Clover config.plist which doesn't have anything weird set-up: https://dl.dropboxusercontent.com/u/10966941/config.plist

@Piker-Alpha: I am giving up, so please, can you kindly comment what the error's impact is on the system? I can only boot without -xcpm with NVidia card removed, hence using the previous AppleIntelCPUManagement kext. But Yosemite is bound to use -xcpm, I think...

from ssdtprgen.sh.

Hi @mackonsti, the "-xcpm_ignore_fv" does not really have any bearing on how your system work. This is because your CPU is not a Haswell anyway so whether you use it or not should not cause a kernel panic. I would suggest for you not to use this flag for the time being and focus on getting your SSDT right with Pike's script.

from ssdtprgen.sh.