4930K still not working about ssdtprgen.sh HOT 99 CLOSED

The system-type is referring to your smbios. You probably don't have a smbios that supports power management with your CPU. If you're using -xcpm it doesn't matter.

from ssdtprgen.sh.

I have set the Mac Pro 6.1 SMBIOS profile, generated by clover configurator. So that should be the right one? Or do I miss something here? What I also saw from a DarwinDump that there, it says "Mac Pro 6,1" for "System Information", but curiously, it states "iMac 13,2" for "Base Board Information". No idea why that is.

Also, with versions prior to 10.0 I did not get the "_CST evaluation failed" error, but it still did not produce the correct values, at least guessing from IPG readings.

from ssdtprgen.sh.

In org.chameleon.plist you have to set SystemType = 3
Maybe you have to set same parameter in config.plist

from ssdtprgen.sh.

And what would that setting in clover be? I do not see a corresponding section in config.plist - there is only BoardType or ChassisType.

from ssdtprgen.sh.

search for smartUPS
http://clover-wiki.zetam.org/Configuration/ACPI/6288a9700444f18366c3768076e5dcad21c288e5#smartUPS

from ssdtprgen.sh.

Thanks for the hint - would not have expected the setting to be there. OK, now so the System Type error vansihes, as does the _ACT error when booting. But now, I am stuck - at least according to IPG - at around x34 with occasional little downward spikes. Also not all P-States seem to be generated, for example x13 - x19 completely missing. And I am not sure if System Type 3 (Server) is the right one here, since Type 1 (Desktop) should be more appropriate?

from ssdtprgen.sh.

First. The i7-4930K is an Ivy Bridge E processor that is supported, meaning that the processor data can be found in the script.

I also see all P-States in the generated SSDT and a _DSM method to set the plugin-type property to 1 but looking at those error (at the top of this page) I'de say the plugin isn't loading. Probably due to a processor scope error (fixed in one of the latest updates of ssdtPRGen.sh).

Do you have: -xcpm under 'Kernel Flags'
in: /L_/P_/SystemC*/com.apple.Boot.plist? If not add it and do not use -f and debug flags.

Also. You have to change "gIvyWorkAround=3" in ssdtPRGen.sh into "gIvyWorkAround=0" when sysctl -n machdep.xcpm.mode return 0 (with 1 the script will make this change for you).

from ssdtprgen.sh.

So meanwhile I updated to 10.9.2 and did as you told. Generated a new SSDT using the latest Version. Also set the -xcpm flag and gIvyWorkAround was already set to "0". Now, I am stuck again at x12, so it is still not working for me. Any ideas what to do?

from ssdtprgen.sh.

I get also these warnings (System type set to "3"):

Processor {.} Declaration(s) found in DSDT
sed: 1: "s/^[\n]*
Warning
Usin ...": unterminated substitute pattern
Warning
Using assumed Scope (_SB) {}:

from ssdtprgen.sh.

Strange. Love to solve this problem, so can you please e-mail me (see script) your DSDT.aml?

from ssdtprgen.sh.

Files are on their way.

from ssdtprgen.sh.

same situation here.
asus x79 sabertooth (bios 4608 latest) and 4930k. using the script, i am stuck at x12.
using as arguments, -c 1 -w 3 -x 1
Override value: (-c) CPU type, now using: Ivy Bridge!
Override value: (-w) Ivy Bridge workarounds, now set to: 3!
Override value: (-x) XCPM mode, now set to: 1!

System information: Mac OS X 10.9.2 (13C64)
Brandstring 'Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz'

Warning: only 60 of 120 processor declarations found!
Warning: only 60 of 120 processor declarations found!
Warning: only 19 of 120 processor declarations found!
Warning: only 60 of 120 processor declarations found!
Warning: only 60 of 120 processor declarations found!
Warning: only 19 of 120 processor declarations found!

from ssdtprgen.sh.

@alphanull,
Ok. Thanks. Files received. Investigating. What is the output of:
ioreg -p IODeviceTree -c IOACPIPlatformDevice -k cpu-type | egrep name | sed -e 's/ *[-|="]//g'

@xelanaiznac,
Using: -w 3 and -x 1 is not what you want.
-w 3 is used for Ivy Bridge workarounds for AppleIntelCPUPowerManagement.kext
-x 1 disables all workarounds and makes you use XCPM (mach_kernel power management).

from ssdtprgen.sh.

Thank you pike. So, which arguments shall i use? I'm on sabertooth x79, 4930k and smbios macpro6,1.

Il giorno 01/mar/2014, alle ore 11:39, Pike [email protected] ha scritto:

@alphanull,
Ok. Thanks. Files received. Investigating. What is the output of:
ioreg -p IODeviceTree -c IOACPIPlatformDevice -k cpu-type | egrep name | sed -e 's/ *[-|="]//g'

@xelanaiznac,
Using: -w 3 and -x 1 is not what you want.
-w 3 is used for Ivy Bridge workarounds for AppleIntelCPUPowerManagement.kext
-x 1 disables all workarounds and makes you use XCPM (mach_kernel power management).

—
Reply to this email directly or view it on GitHub.

from ssdtprgen.sh.

I would say -w 3 because wasn't that what worked before?

Also. Can you please tell me what the output of the above ioreg command is, so that I can fix this warning: "Warning: only 60 of 120 processor declarations found!"

from ssdtprgen.sh.

output of ioreg -p IODeviceTree -c IOACPIPlatformDevice -k cpu-type | egrep name | sed -e 's/ *[-|="]//g’:
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name
name

Alex Canzian
Personal Wellness Coach
+39 3473300809

Il giorno 01/mar/2014, alle ore 12:15, Pike [email protected] ha scritto:

I would say -w 3 because wasn't that what worked before?

Also. Can you please tell me what the output of the above ioreg command is, so that I can fix this warning: "Warning: only 60 of 120 processor declarations found!"

—
Reply to this email directly or view it on GitHub.

from ssdtprgen.sh.

My output is exactly the same as xelanaiznac's (so no need to post it again)

from ssdtprgen.sh.

Ok. The problem is that Method _STA is not executed by OS X and that is why my check fails. Let's add another filter: -k clock-frequency That should work. Please confirm.

ioreg -p IODeviceTree -c IOACPIPlatformDevice -k cpu-type -k clock-frequency | egrep name | sed -e 's/ *[-|="]//g'

from ssdtprgen.sh.

That gives me this output, ie only the active cores:

name
name
name
name
name
name
name
name
name
name
name
name

from ssdtprgen.sh.

Ups, seems that my copy & paste was mangled. In essence, same output as above, but this time only going up to "C00B"

from ssdtprgen.sh.

The warning about found/missing ACPI processor declarations should be fixed in v12.3. Please confirm. Thanks!

from ssdtprgen.sh.

fixed in my case!
Thank you

from ssdtprgen.sh.

for me it's still no working. The warning about found/missing ACPI processor declarations are fixed but i'm still stuck at x12

from ssdtprgen.sh.

ioreg -p IODeviceTree -c IOACPIPlatformDevice -k cpu-type -k clock-frequency | egrep name | sed -e 's/ *[-|="]//g' gives me this:
name C000>
name C001>
name C002>
name C003>
name C004>
name C005>
name C006>
name C007>
name C008>
name C009>
name C00A>
name C00B>

from ssdtprgen.sh.

try flag -w 3
if 0 also for me if 0 stuck to 12

from ssdtprgen.sh.

So which flags did you use? Only -w3?

Alex Canzian
Personal Wellness Coach
+39 3473300809

Il giorno 01/mar/2014, alle ore 20:47, fabiosun [email protected] ha scritto:

try flag -w 3
if 0 also for me if 0 stuck to 12

—
Reply to this email directly or view it on GitHub.

from ssdtprgen.sh.

yes

from ssdtprgen.sh.

thank you, now perfectly working!

from ssdtprgen.sh.

OK, can confirm that warnings are gone, but actual output just seems to be the same. And as before, if I try the Ivy workaround, I am stuck at around 3,4 GHz again, but Wattage shows that there is at least partial PM working. All according to IPG, which I assume gives the most reliable output. But even with -w 3, still these values seem not right to me. One thing catched my attention:

            /* Low Frequency Mode */
            Package (0x06) { 0x04B0, 0x008938, 0x0A, 0x0A, 0x0C00, 0x0C00 },
            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 }

So why are you using "Zero" for Power? Also the Freq values seem to be off, cannot got to 800 MHz with 4930K.

Now, for comparison the SSDT which gives me the best output so far, the one I am actually using at the moment:

/*
 * Intel ACPI Component Architecture
 * AML Disassembler version 20100331
 *
 * Disassembly of iASLQ0SWw7.aml, Sat Mar  1 23:29:05 2014
 *
 *
 * Original Table Header:
 *     Signature        "SSDT"
 *     Length           0x0000066B (1643)
 *     Revision         0x01
 *     Checksum         0x71
 *     OEM ID           "APPLE "
 *     OEM Table ID     "CpuPm"
 *     OEM Revision     0x00008400 (33792)
 *     Compiler ID      "INTL"
 *     Compiler Version 0x20100331 (537920305)
 */
DefinitionBlock ("iASLQ0SWw7.aml", "SSDT", 1, "APPLE ", "CpuPm", 0x00008400)
{
    External (\_SB_.C00B, DeviceObj)
    External (\_SB_.C00A, DeviceObj)
    External (\_SB_.C009, DeviceObj)
    External (\_SB_.C008, DeviceObj)
    External (\_SB_.C007, DeviceObj)
    External (\_SB_.C006, DeviceObj)
    External (\_SB_.C005, DeviceObj)
    External (\_SB_.C004, DeviceObj)
    External (\_SB_.C003, DeviceObj)
    External (\_SB_.C002, DeviceObj)
    External (\_SB_.C001, DeviceObj)
    External (\_SB_.C000, DeviceObj)

    Scope (\_SB.C000)
    {
        Name (APLF, One)
        Name (APSN, 0x29)
        Name (APSS, Package (0x20)
        {
            Package (0x06)
            {
                0x0F3C, 
                0x0001FBD0, 
                0x0A, 
                0x0A, 
                0x2700, 
                0x2700
            }, 

            Package (0x06)
            {
                0x0ED8, 
                0x0001FBD0, 
                0x0A, 
                0x0A, 
                0x2600, 
                0x2600
            }, 

            Package (0x06)
            {
                0x0E74, 
                0x0001FBD0, 
                0x0A, 
                0x0A, 
                0x2500, 
                0x2500
            }, 

            Package (0x06)
            {
                0x0E10, 
                0x0001FBD0, 
                0x0A, 
                0x0A, 
                0x2400, 
                0x2400
            }, 

            Package (0x06)
            {
                0x0DAC, 
                0x0001FBD0, 
                0x0A, 
                0x0A, 
                0x2300, 
                0x2300
            }, 

            Package (0x06)
            {
                0x0D48, 
                0x0001FBD0, 
                0x0A, 
                0x0A, 
                0x2200, 
                0x2200
            }, 

            Package (0x06)
            {
                0x0CE4, 
                0x000190E3, 
                0x0A, 
                0x0A, 
                0x2100, 
                0x2100
            }, 

            Package (0x06)
            {
                0x0C80, 
                0x0001802E, 
                0x0A, 
                0x0A, 
                0x2000, 
                0x2000
            }, 

            Package (0x06)
            {
                0x0C1C, 
                0x00016FC8, 
                0x0A, 
                0x0A, 
                0x1F00, 
                0x1F00
            }, 

            Package (0x06)
            {
                0x0BB8, 
                0x00015FB2, 
                0x0A, 
                0x0A, 
                0x1E00, 
                0x1E00
            }, 

            Package (0x06)
            {
                0x0B54, 
                0x00014FE9, 
                0x0A, 
                0x0A, 
                0x1D00, 
                0x1D00
            }, 

            Package (0x06)
            {
                0x0AF0, 
                0x0001406F, 
                0x0A, 
                0x0A, 
                0x1C00, 
                0x1C00
            }, 

            Package (0x06)
            {
                0x0A8C, 
                0x00013141, 
                0x0A, 
                0x0A, 
                0x1B00, 
                0x1B00
            }, 

            Package (0x06)
            {
                0x0A28, 
                0x00012260, 
                0x0A, 
                0x0A, 
                0x1A00, 
                0x1A00
            }, 

            Package (0x06)
            {
                0x09C4, 
                0x000113CB, 
                0x0A, 
                0x0A, 
                0x1900, 
                0x1900
            }, 

            Package (0x06)
            {
                0x0960, 
                0x00010580, 
                0x0A, 
                0x0A, 
                0x1800, 
                0x1800
            }, 

            Package (0x06)
            {
                0x08FC, 
                0xF780, 
                0x0A, 
                0x0A, 
                0x1700, 
                0x1700
            }, 

            Package (0x06)
            {
                0x0898, 
                0xE9CA, 
                0x0A, 
                0x0A, 
                0x1600, 
                0x1600
            }, 

            Package (0x06)
            {
                0x0834, 
                0xDC5D, 
                0x0A, 
                0x0A, 
                0x1500, 
                0x1500
            }, 

            Package (0x06)
            {
                0x07D0, 
                0xCF39, 
                0x0A, 
                0x0A, 
                0x1400, 
                0x1400
            }, 

            Package (0x06)
            {
                0x076C, 
                0xC25D, 
                0x0A, 
                0x0A, 
                0x1300, 
                0x1300
            }, 

            Package (0x06)
            {
                0x0708, 
                0xB5C8, 
                0x0A, 
                0x0A, 
                0x1200, 
                0x1200
            }, 

            Package (0x06)
            {
                0x06A4, 
                0xA979, 
                0x0A, 
                0x0A, 
                0x1100, 
                0x1100
            }, 

            Package (0x06)
            {
                0x0640, 
                0x9D70, 
                0x0A, 
                0x0A, 
                0x1000, 
                0x1000
            }, 

            Package (0x06)
            {
                0x05DC, 
                0x91AD, 
                0x0A, 
                0x0A, 
                0x0F00, 
                0x0F00
            }, 

            Package (0x06)
            {
                0x0578, 
                0x862E, 
                0x0A, 
                0x0A, 
                0x0E00, 
                0x0E00
            }, 

            Package (0x06)
            {
                0x0514, 
                0x7AF3, 
                0x0A, 
                0x0A, 
                0x0D00, 
                0x0D00
            }, 

            Package (0x06)
            {
                0x04B0, 
                0x6FFC, 
                0x0A, 
                0x0A, 
                0x0C00, 
                0x0C00
            }, 

            Package (0x06)
            {
                0x044C, 
                0x6548, 
                0x0A, 
                0x0A, 
                0x0B00, 
                0x0B00
            }, 

            Package (0x06)
            {
                0x03E8, 
                0x5AD5, 
                0x0A, 
                0x0A, 
                0x0A00, 
                0x0A00
            }, 

            Package (0x06)
            {
                0x0384, 
                0x50A4, 
                0x0A, 
                0x0A, 
                0x0900, 
                0x0900
            }, 

            Package (0x06)
            {
                0x0320, 
                0x46B4, 
                0x0A, 
                0x0A, 
                0x0800, 
                0x0800
            }
        })
        Method (ACST, 0, NotSerialized)
        {
            Store ("Method C000.ACST Called", Debug)
            Store ("C000 C-States    : 13", Debug)
            Return (Package (0x06)
            {
                One, 
                0x04, 
                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000000, // Address
                            0x01,               // Access Size
                            )
                    }, 

                    One, 
                    0x03, 
                    0x03E8
                }, 

                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000010, // Address
                            0x03,               // Access Size
                            )
                    }, 

                    0x03, 
                    0xCD, 
                    0x01F4
                }, 

                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000020, // Address
                            0x03,               // Access Size
                            )
                    }, 

                    0x06, 
                    0xF5, 
                    0x015E
                }, 

                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW, 
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000030, // Address
                            0x03,               // Access Size
                            )
                    }, 

                    0x07, 
                    0xF5, 
                    0xC8
                }
            })
        }

        Method (DTGP, 5, NotSerialized)
        {
            If (LEqual (Arg0, Buffer (0x10)
                    {
                        /* 0000 */    0xC6, 0xB7, 0xB5, 0xA0, 0x18, 0x13, 0x1C, 0x44, 
                        /* 0008 */    0xB0, 0xC9, 0xFE, 0x69, 0x5E, 0xAF, 0x94, 0x9B
                    }))
            {
                If (LEqual (Arg1, One))
                {
                    If (LEqual (Arg2, Zero))
                    {
                        Store (Buffer (One)
                            {
                                0x03
                            }, Arg4)
                        Return (One)
                    }

                    If (LEqual (Arg2, One))
                    {
                        Return (One)
                    }
                }
            }

            Store (Buffer (One)
                {
                    0x00
                }, Arg4)
            Return (Zero)
        }

        Method (_DSM, 4, NotSerialized)
        {
            Store (Package (0x02)
                {
                    "plugin-type", 
                    One
                }, Local0)
            DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
            Return (Local0)
        }
    }

    Scope (\_SB.C001)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C002)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C003)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C004)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C005)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C006)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C007)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C008)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C009)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C00A)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

    Scope (\_SB.C00B)
    {
        Method (APSS, 0, NotSerialized)
        {
            Return (\_SB.C000.APSS)
        }

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

Perfect Readings with IPG, showing Power usage going as low as 10W (all) respective 2W (cores only) and all P States apparently reached, hovering around x12 - x16 when idling, and up to x39 when stressing. However even with this SSDT, HW Monitor shows only x12/x34 and also AICPUPMI does not show all P States on my main install. (But strangely on my test system with a plain install, it does!)

So I don't know what to believe, but since HW Monitor at least reflects the low Wattage readings from IPG it might me more a reporting problem with HW Monitor (and maybe AICPUPMI as well)

Hope this helps, thank you!

from ssdtprgen.sh.

Ah and as you can see, the APSN value seems to pretty "funky" to me but I guess - from my limited knowledge - that the APSS values are spot on. So, the workarounds seem not to be needed at all. Also uses only one ACST method instead of two. And last but not least -xcpm has no effect at all since my CPU does not seem to use this mode anyways.

from ssdtprgen.sh.

i've just tried msrdumper.kext
i found out that my hack is only using 3 multipliers, x12, x34 and x39

from ssdtprgen.sh.

Take the output of any diagnostics tool with a grain of salt imho. They may not show you everything. Recheck with IPG. (But even that may be faulty ...)

from ssdtprgen.sh.

Sorry for my ignorance but, is ipg intel power gadget?
It shows temperatures and wattage, that's right?

Alex Canzian
Personal Wellness Coach
+39 3473300809

Il giorno 02/mar/2014, alle ore 00:00, alphanull [email protected] ha scritto:

Take the output of any diagnostics tool with a grain of salt imho. They may not show you everything. Recheck with IPG. (But even that may be faulty ...)

—
Reply to this email directly or view it on GitHub.

from ssdtprgen.sh.

Yes, and most importantly shows also Freqs! Give it a try, I'd say and report what it does with the different SSDTs. And at least with HWMonitor, I am pretty sure it's reportings are simply wrong.

from ssdtprgen.sh.

I use Zero for power (wattage) because that is what Apple expects when a frequency isn't used, but things have changed again after the release of Mavericks, and thus now they don't want the extra P-States anymore. At least not when -xcpm is used, which by the way may require you to use Omni's mach_kernel patch.

Anyway. As far as I know is the script correct. You can verify that yourself by using this script:
https://pikeralpha.wordpress.com/2014/02/08/new-repository-for-debugmachkernel-sh/

That gives you everything we need. And when something isn'ty right then e-mail me the output.

p.s. Your APSN (out-of-reach) and APLF (should be Zero) value are incorrect. I guess you will find that out after running debugMachKernel.sh and looking at the log file ;)

from ssdtprgen.sh.

As I said I neither need -xcpm nor any patches to get it work. Does not make any differences if I use this setting or not. xcpm is simply not used! And the other script may be not perfect, but it gives me better output than yours, thawt is just a fact. I do not know why, but I just report what I see. So you still think your script is not at fault?

from ssdtprgen.sh.

Easy. E-mail me your debug output and I will show you what the problem is.

from ssdtprgen.sh.

OK. What output do you exactly need? I already use a debugging kernel from time to time, but it produces a whole lot of additional output. So you want everything or shall I filter the output before?

from ssdtprgen.sh.

OK. So I sent you the whole output anyway. I did 3 runs:

1. using my current "best" SSDT (the one by Balamut)
2. using SSDT generated by ssdtPRgen (default settings)
3. using SSDT by ssdtPRgen using flag "-w 3" and System Type = 3 (though the latter does not seem to make any differences)

I also took some IPG screens with light load (left), a short Geekbench run (middle) and just the machine idling for a while (right hand side) to check the output with different loads.

The results were essentially the same as always, no matter which ssdtPRgen version I tried (starting from v8):

1. perfect IPG readings, correlating to CPU load, AICPUPM shows all P-States generated
2. locked at x12. AICPUPMI shows also Turbo States, but this readings maybe just wrong, since Turbo is never reached. Proof: Geekbench score is at around 1/3 of what it should be, so no Turbo at all, effectly running at 1200MHz. IPG also shows multiplier locked at x12
3. Somewhat better IPG output, wattages similar to 1) but freqs only around 34x, lower states apparently never reached. Geekbench score is OK, but AICPUPMI does also not show all P-States, especially missing the lower ones.

So my verdict still is - until I am proved wrong:

1. SSDT I posted above clearly gives the best results
2. ssdtPRGen for 4930K clearly fails with default settings, leaving me locked at x12. AICPUPMI output is apparently wrong too here, since there is effectively only one multiplier ever reached.
3. ssdtPRGen with "-w 3" gives somewhat better results, but imho still beaten by 1) - just compare the AICPUPMI / IPG readings and decide for yourself.

Hope this helps!

from ssdtprgen.sh.

i agree 100% with what you say.
same identical results

Alex Canzian
Personal Wellness Coach
+39 3473300809

Il giorno 02/mar/2014, alle ore 17:10, alphanull [email protected] ha scritto:

OK. So I sent you the whole output anyway. I did 3 runs:

1. using my current "best" SSDT (the one by Balamut)
2. using SSDT generated by ssdtPRgen (default settings)
3. using SSDT by ssdtPRgen using flag "-w 3" and System Type = 3 (though the latter does not seem to make any differences)

I also took some IPG screens with light load (left), a short Geekbench run (middle) and just the machine idling for a while (right hand side) to check the output with different loads.

The results were essentially the same as always, no matter which ssdtPRgen version I tried (starting from v8):

1. perfect IPG readings, correlating to CPU load, AICPUPM shows all P-States generated
2. locked at x12. AICPUPMI shows also Turbo States, but this readings maybe just wrong, since Turbo is never reached. Proof: Geekbench score is at around 1/3 of what it should be, so no Turbo at all, effectly running at 1200MHz. IPG also shows multiplier locked at x12
3. Somewhat better IPG output, wattages similar to 1) but freqs only around 34x, lower states apparently never reached. Geekbench score is OK, but AICPUPMI does also not show all P-States, especially missing the lower ones.

So my verdict still is - until I am proved wrong:

1. SSDT I posted above clearly gives the best results
2. ssdtPRGen for 4930K clearly fails with default settings, leaving me locked at x12. AICPUPMI output is apparently wrong too here, since there is effectively only one multiplier ever reached.
3. ssdtPRGen with "-w 3" gives somewhat better results, but imho still beaten by 1) - just compare the AICPUPMI / IPG readings and decide for yourself.

Hope this helps!

—
Reply to this email directly or view it on GitHub.

from ssdtprgen.sh.

Glad I am not the only one - I doubted my own sanity at some time, but now I have run so many tests (and wasted so many hours for months now) - sorry I cannot help myself, but I am always coming to the same conclusion. I hope this data is enough to help Pike fix his script - and yes Pike, while I really appreciate your work, in this special case I continue to think that ssdtPRgen is still buggy (IMHO!)

There must be something, and yes also the other script is not perfect, but simply "better" (IMHO!). So let's hope we get a perfect SSDT created with ssdtPRgen.

PS: you also can see that C3_residency is still at "0", but it seems to work anyway? Still wonder if this is a real issue or just some false reporting.

from ssdtprgen.sh.

alphanull, could you try in condition 3 to use a MacMini6.2 smbios.plist and see output result with ipg .aicpupmi and hw
in my tests, i think you should see same results of your condition 1
thanks

from ssdtprgen.sh.

I do not think that any other SMBIOS than 6,1 would be better. If I use SMBIOS 5,1 for example I have no sleep, and no shutdown. SMBIOS 6,1 gives best results and is what should be used, as this is most close to my System. MacMini SMBIOS is not LGA2011 based for example. And I also do not want to use System Type 3. So what you proposed sounds like a workaround of a workaround. Frankly, I'd prefer a correct SSDT over even more patching and hacking. And I still think the SSDT is not correct, I only have to look at the APSS values and I think this is a pretty clear case. So why using the "wrong" SMBIOS instead of fixing the SSDT? shrug

from ssdtprgen.sh.

Plus, as I see it, the "workarounds" are needed For Ivy, but not Ivy-E. Ivy-E is much more close to the XEONs used in the nMP, in fact this is almost the same CPU. Another reason to use the 6,1 SMBIOS (all imho!)

from ssdtprgen.sh.

alphanull I have an ivy bridge xeon ep cpu that is the same of new macpro
with macmini6.2 plist you see all steps and all output in all software that you use to check(ipg or hw)
so, maybe, software that we are using to check not read well with new cpu
for me it is only an output problem because I have same behavior and same wattage using different smbios.plis definition
and for that I was curious if you could do tha try and see the results
ps i am with you that is better to fix ssdt, but maybe all this tries coul help to achieve it

from ssdtprgen.sh.

OK. I'll try now with macmini SMBIOS.

from ssdtprgen.sh.

and then you can also mantain your 6.1 system definition
it is possible to achieve correct output also change stepdict from6.2 macmini inside 6.1 mac pro
and this "trick" is working for different cpu type (3930k,3960x, and 2690 v2)

from ssdtprgen.sh.

if you can try only to change only stepdict so you could mantain other 6.1 pro parameters

from ssdtprgen.sh.

OK, so I can confirm that the readings with macmini SMBIOS are in fact the same as with my other SSDT (and 6,1 SMBIOS). Strange, but maybe this has something to do with the SSDT values being actually generated for Ivy (not Ivy E), and the macmini just also using Ivy? And how would you change the "stepdict"? And still, why not generating the "correct" SSDT in the first place instead of even more patching? And what about OC, will that work, too with this trick?

from ssdtprgen.sh.

Thank you. I have received your log files and quickly checked them. Oops. Things are not OK. First. I see this line in your log files:
AICPUPMI: CPU Low Frequency Mode.............: 1200 MHz
Confirming that the script is correctly generates a SSDT with 1200 MHz as lowest possible P-State. The number of P-States and data in it are also correct, but then I found this:

kernel[0]: Registering Virtual Processor

That message means that your processor is not properly detected!

I also cannot find a single line of debug output from the XCPM plugin, which is also called when the CPU is properly detected. Please visit this forum thread:

http://www.insanelymac.com/forum/topic/295200-testers-needed-cpu-power-management-for-sb-and-ib-xeons-or-i7-39xx-on-x79-or-c60x-chipset/page-1

Get the patched AppleIntelCPUPowerManagement.kext and try again. Trust me. You HAVE to get rid of that message first.

p.s. Please also try -xcpm to see what that gices you... but only after you've downloaded and installed the patched kext.

from ssdtprgen.sh.

ei alphanull.. we are all in same boat..we are testing and studying
sorry me for not to be precise in instructions but i am on an ipad air and i don't remember all terms correctly
so, if you want try do this
use macpro6.1 smbios.plist
go in S/L/E
copy x86platformplugin.kext
inside info.plist
find F6xxxxxxxxxxED and copy stepdict from it
put it in F6something (MacPro6.1 system definitioon) deleting that one present inside
rebuild cache and reboot
now you should have the best PM for your rig
IMHO, changing or not stepdict is the same and it is useful only for having correct output wit ipg or hw
wattage is the same with original macpro6.1 or modified one
for me this means that if I see 30 multiplier e 1.5 w in idle and in ipg or hw, it is identical if I see 12 multiplier and same wattage(1.5 in idle)

from ssdtprgen.sh.

Pike, are you absolutely sure? Of course I know this thread, and of course I used also the patched kext before - because I had to or else PM would not work. BUT, starting with 10.9.2b5 or b6 this patching wasn't needed anymore, ie I got the very same results if I patched or not (in contrast to older betas!).

And rightly so, after patching it now again, literally nothing has changed, I get the same messages as before. And I never had XCPM mode and apparently it works nonetheless. I always get: IOPPF: AppleIntelCPUPowerManagement mode and not XCPM mode. Therefore also adding -xcpm is doing absolutely nothing.

from ssdtprgen.sh.

Yes. Trust me. I am 100% sure about what I said; seeing the message about the virtual processor in the log files was also what I was expecting. I am after all already working hundreds of hours on power management issues. I know what the script does, and if the patched kexts isn't working for you, then that is not my fault nor that of ssdtPRGen.sh because all it does is creating a SSDT that is used by Apple.

And No. I am not interested in stuff like using Name (APLF, 0x01) to set it to unsupported frequency (900 MHz for your processor) which we used as a Ivy Bridge workaround some time ago, or using Name (APSN, 0x29) when the package length is only 0x20 and thus even that is wrong. What I want is that power management works exactly the same as Apple is doing in their hardware. Nothing else matters. And I have blogged about modding APSN and APLF for far too long to be blamed for something that is not my fault. Nonetheless I am still interested in trying to solve the puzzle. Even when my time dries out.

Simply put. What you are seeing in not right. Again. Get that message fixed and see if you can get the messages from the XCPM plugin, because that is going to help you convince that I was right all the time ;)

Cheers,

Pike

from ssdtprgen.sh.

What I want is working Power Management, and from my own POV that does not have to be exactly the same as Apple does. Why should it? I have no Apple hardware, and I am happy when it works (and it does). Nothing else matters. So, how I am supposed to get rid of this message? I have absolutely no clue! I already said that things like setting -xcpm are doint nothing. What am I supposed to do?

from ssdtprgen.sh.

Power management in OS X is only controlled, properly, by the mach_kernel (XCPM) or AppleIntelCPUPowerManagement.kext when you set it up properly. Unfortunately this is not the case for your setup, because I found the "virtual processor" message in your log files, and no matter how you look at it, in the end it is still not right.

In short: You need a patched mach_kernel or a patched copy of AppleIntelCPUPowerManagement.kext because then and only then will power management be controlled by the mach_kernel or AppleIntelCPUPowerManagement.kext And since you are using OS X you have to set it up like Apple expects. Even when you use an unsupported processor.

The problem with your perspective is that you think that the script should fix everything. Even after you've skipped such an important step in the setup process and thus to me this is not a bug in ssdtPRGen.sh but a user setup error.

from ssdtprgen.sh.

so you are saying that it’s not possible to have a vanilla installation with the 4930k, because it needs a modified appleintelcpupowermanagement or a modified mach_kernel.
the issue is that even with the modified appleintelcpupowermanagement kext made by omni, your script isn’t working
so, what must we do?

Alex Canzian
Personal Wellness Coach
+39 3473300809

Il giorno 03/mar/2014, alle ore 14:17, Pike [email protected] ha scritto:

Power management in OS X is only controlled, properly, by the mach_kernel (XCPM) or AppleIntelCPUPowerManagement.kext when you set it up properly. Unfortunately this is not the case for your setup, because I found the "virtual processor" message in your log files, and no matter how you look at it, in the end it is still not right.

In short: You need a patched mach_kernel or a patched copy of AppleIntelCPUPowerManagement.kext because then and only then will power management be controlled by the mach_kernel or AppleIntelCPUPowerManagement.kext And since you are using OS X you have to set it up like Apple expects. Even when you use an unsupported processor.

The problem with your perspective is that you think that the script should fix everything. Even after you've skipped such an important step in the setup process and thus to me this is not a bug in ssdtPRGen.sh but a user setup error.

—
Reply to this email directly or view it on GitHub.

from ssdtprgen.sh.

But my PM DOES use AppleIntelCPUPowerManagement.kext all the time? And I already said that I tried with a patched version just yesterday, and nothing has changed. So what exactly am I supposed to do? Where is a patched kernel? Haven't seen any in this regard. And btw: there are a lot of reports now with people having exact the same symptoms like me. All user error?

And at least with the SSDT you think is faulty, I do not need to patch anything. System boots fine with all set to vanilla. The only kext that needs a patch is AppleHDA, and nothing else. Runs fine! And my CPU uses about 4-5W right now as I am typing. Just. works. Not perfect maybe, but better than nothing imho. Before, it was more like 30-40W even when idling.

So, if all users with 4930K are having wrong setup (as all so far I heard from seem to have similar issues) what EXACTLY are we supposed to do? Please enlighten us, I don't know what to do else. It's not that I haven't tried lot's of things before, so any concrete(!) advice would be very much appreciated.

from ssdtprgen.sh.

@xelanaiznac,

If you are using the patched AppleIntelCPUPowerManagment.kext then you should not see the "virtual processor" message in your (debug enabled) system.log and if ssdtPRGen.sh isn't working, then you should see other power management related errors. Can you confirm that? I mean. That was why I asked for the debug output in system.log

@alphanull,

If you look back in time, when power management for Intel Pentium processors was first figured out, it took many months in an insane long forum thread over at insanelymac.com where people repeated the same errors over and over again... simply because nobody at that time knew what to do, and that problem is what I see here... be it with a different processor. But you keep blaming the messenger (me) for telling you that something is still not right.

In short; Is the "virtual processor" message gone with the patched version of AppleIntelCPUPowerManagment.kext or not? If not then the patch is clearly not working.

from ssdtprgen.sh.

I do not blame you for anything - it is just that I do not know what to do now. So yes, as I said before the "virtual processor" message does not go away if I use the patched AppleIntelCPUPowerManagment.kext

However at least the kext enabled PM when the unpatched did not (before b5 or so). Without any of these two, I got the message "Unknown CPU", so at least someting happened there.

So in short, you would say the problem is Omni's patch not working correctly, and that XCPM mode is a requirement for Ivy-E?

from ssdtprgen.sh.

AppleIntelCPUPowerManagement.kext was developed for pre-Ivy Bridge processor support. The X86Platform*.kexts where first used with the release of the Ivy Bridge processor based Mac models, and since you own a i7-4930K I would say yes. If I was you then I would run ssdtPRGen with -w 3, enable debug output in com.apple.Boot.plist / run debugMachKernel.sh and e-mail me the debug output of system.log because by the time you see output that starts with: X86platformPlugin then we can start fixing things.

from ssdtprgen.sh.

But I already sent you these files? Just look at "bootlog ssdtprgen -w 3". There I can see:

02/03/14 07:49:51,000 kernel[0]: X86PlatformShim::start(X86PlatformPlugin) <1>

from ssdtprgen.sh.

PS: 4930K is not Ivy bridge, but Ivy-E. AFAIK that is quite a difference?

from ssdtprgen.sh.

OK, so now I booted with more debug output and I hope I have now the entries you are searching for - X86platformPlugin messages now included. File is on it's way. Thank you!

from ssdtprgen.sh.

The i7-4930K is based on Ivy Bridge and uses the same MSR's. With a few exceptions. Which is important to get power management functional.

Thanks for the updated log file. Now I see a lot more (interesting) info. Some of it confirms that the SSDT is correct. I do see no ACPI errors that can be tracked back to ssdtPRGen.sh, but I do see this:

ACPI Error (psargs-0464): [RAMB] Namespace lookup failure, AE_NOT_FOUND
ACPI Exception: AE_NOT_FOUND, Could not execute arguments for RAMW (20100528/nsinit-450)

I also found this error: [AGPM Controller] unknownPlatform
Get that fixed (unrelated to this issue).

And I still see this: "Registering Virtual Processor".
Is it gone if you use -xcpm in com.apple.Boot.plist? If not we have to bin-patch the mach_kernel/kext.

from ssdtprgen.sh.

Hi Pike, thanks for feedback. So:

• RAMB / RAMW seem to be unrelated, nevertheless of course I would like to fix this - but how? Not sure if this is actually a symptom of the Clover Aptio/lowmem Fix, but really this is just guessing, I do not know what these values actually mean.
• AGPM Controller unknown: GPU specific, but apparently unrelated. I have also GPU PM problems in combination with OpenCL - but this is a well known bug with GK110 and should be fixed by NVIDIA. Don't know if I can do anything about that.
• atleast when I boot with -xcpm set as bootflag in clover, the "virtual processor" message is still there. Dunno if this will change when I actually set -xcpm in boot.plist, but that's the same as setting the boot flag, correct? So the answer would be "no".

from ssdtprgen.sh.

The message: "Registering Virtual Processor" comes from AppleIntelCPUPowerManagement.kext so even with the -xcpm boot flag your are not using XCPM but the kext.

The problem is that function _cpuid_set_info() in the mach_kernel only checks for two Ivy Bridge processor models (0x3A and 0x3E) and then it sets the processor family type to CPUFAMILY_INTEL_IVYBRIDGE (0x1f65e835/526772277) but that doesn't happen for your processor (0x3B) so a kernel patch is required.

from ssdtprgen.sh.

ok, so it is not possible to have a vanilla installation with the 4930k.
what about the i7 4960x instead?

Alex Canzian
Personal Wellness Coach
+39 3473300809

Il giorno 05/mar/2014, alle ore 14:54, Pike [email protected] ha scritto:

The message: "Registering Virtual Processor" comes from AppleIntelCPUPowerManagement.kext so even with the -xcpm boot flag your are not using XCPM but the kext.

The problem is that function cpuidset_info() in the mach_kernel only checks for two Ivy Bridge processor models (0x3A and 0x3E) and then it sets the processor family type to CPUFAMILY_INTEL_IVYBRIDGE (0x1f65e835/526772277) but that doesn't happen for your processor (0x3B) so a kernel patch is required.

—
Reply to this email directly or view it on GitHub.

from ssdtprgen.sh.

OK, so as I understand there are different modes of PM, and I use the AppleIntelCPUPowerManagement.kext at the moment. On the other hand, what would be the benefit of using XCPM mode? At least there seem to be some kind of PM going on right now, with my CPU using 11W in idle compared to 40W as before.

So what would be your advice now? As I am not competent enough to patch the kernel for myself, I think I will have to wait for somebody doing it, and using my current SSDT as an interim measure. At least it seems to do no harm, or is my CPU at risk with such a solution?

Else, I do not know what to do now. Maybe using the stepdict from macmini in addition?

from ssdtprgen.sh.

I have a 4930k. When I use the script I do get better power consumption and use of turbo speeds. But after some time I start getting crashes, consistently.

I use Clover and don't get any weird errors on boot-up in Verbose mode.

from ssdtprgen.sh.

After a long read of everything I could find regarding the 4930k, I tried all the suggestions Pike made in these posts and after replacing the AICPUPM kext with the one from omni, adding -xcpm kernel flag in Chameleon, and generating a SSDT from Pike's script (without any options), everything seems to be working good as far as I can tell. And trust me, I've been trying to get this to work for a while now!

Using HWMonitor and the Intel power tool, My CPU is jumping from 12x to max 38x and GPU jumps as well (but haven't checked the results yet). Not sure why CPU doesn't go to x39 but that's for another day ;-)

So Pike (and everyone else who helped making this work), thanks a lot!

My hardware: i7-4930K, MB: GA-X79S-UP5-Wifi (BIOS F4, Original) in case anyone wants to know

from ssdtprgen.sh.

Drumndan, with your settings are you sure you are actually using XCPM mode? Can you double check this? Bc for me setting -xcpm (and using patched kext) made no difference.

from ssdtprgen.sh.

FYI: I managed to achieve a good setup with ssdtPRGen (default settings) - but only with the help of a special version of FakeSMC. So there was definetly one piece of the puzzle missing, but seems that all is well now. Updated HWMonitor now also shows corrects freqs. Therefore, would it might make sense for ssdtPRGen to spit out a warning regarding CPU types which need further treatment?

from ssdtprgen.sh.

Hi alphanull,

Where did you get this special version of FakeSMC? I am in the same boat as you trying to get a 4960X working on a GA-X79-UP4.

from ssdtprgen.sh.

Look here: http://rampagedev.wordpress.com/dsdt-downloads/ The kext is included in the DMG. Keep in mind that this is indeed a special build, so do not auto update FakeSMC after installing that. You can update HWMonitor though, the newer versions also show correct freqs and multipliers now. Also the kext is specifically keyed for the MacPro 6,1 SMBIOS, so you should use that as well. Furthermore, there still might be issues for GB boards, so no guarantees that this works with yours. At least you have to make sure that you have an unlocked BIOS. In your case you should not need a patched AICPUPM kext with Ivy-E, at least it works unpatched with 4930K.

from ssdtprgen.sh.

hi alphanull,
do you understand well what this "special FakeSMC " do?
You could achieve same results editing by yourself proper files in x86platformplugin/resources/Mac-F60DEB81FF30ACF6.plist/IOPlatformPowerProfile/StepContextDict and in my humble opinion is not the right way to achieve perfect PM! ;-)
I would like also to know netkas and kozlek opinion about this mod.
And, overall this result is achieved from the start in many users try on omni's thread on InsanelyMac, then adjusted by stinga11 with a dummy kext and then repackaged by rampage dev in his compilation dmg
Pike, what do you think about it?
sorry alphanul and Pike for big OT here

from ssdtprgen.sh.

I have no idea what is special about this version, but it works. In the patched FakeSMC kext, there is a plugin called "test.kext" - this is the one which does the "magic" I assume. And inside this plugin, you can see a file called "Mac-F60DEB81FF30ACF6.plist" which contains some stepdict infos and other stuff. Seems like this info is merged somehow with the X86 platform plugin. I would guess this is a similar thing like your patch, but "automatic" and/or maybe with some tweaks to the values. Think you should ask Andrew about that for more details. He also objected against using Mac Mini SMBIOS or it's stepdict, apparently that causes side effects for some. AFAIK they also tried to merge the patches into the main FakeSMC trunk but got problems after that. Of course it would be very nice if this patch would be included in the main distribution. All in all - since you now can use Pike's script, also with OC it seems - this seems to be the best solution so far.

from ssdtprgen.sh.

alphanull, what do you mean with it works now?
Have you different (and lower) wattage using it ?
Do you have different behavior on your system?
Test.kext inject MAcMini6.2 StepContextDict values (or similar) here Mac-F60DEB81FF30ACF6.plist
We can call it a placeholder or a dummy kext like other for audio or network stuff
Personally I don't like that this kext is inside in a vital kext like fakeSMC (but it is only my opinion)
IMHO with MacMini6.2 StepContextDict inject you only see printed out multiplier values which were always there (with -w 3 option in Pike's script)and never printed out before by IPG or HW, but visible with AICPUPMI (always with a proper SSDT)
I have a pretty similar nMacPro CPU (XEON 2690 V2) and this are the steps I see without any special fakeSMC:
A) AICPUPMI: CPU P-States [ (12) 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 ]
without running anything and in a normal use

after running Luxmark render:
B) [ 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 (30) 31 32 33 34 35 36 ]

And thats all!

Patching StepContextDict from MacPro6.1 to MAcMini6.2 one produces only a faster output of all PStates
With both watts and temperatures are the same (and fine)

So I think that in my case StepContextDict patch is useful only for cosmetic

If you can, if you are with macPro6.1 unpatched similar to my condition A (according to your cpu multiplier steps) try to run luxmark and you will see all steps also in AICPUPMI output.

Maybe, HW and IPG programmers could correct this, that in my case is only a cosmetic issue

PS.
also it is not necessary changing all Normal, Background and RealTime values in StepContextDict, but it is possible to change it accordly to user need, also with other stecontext dict different from MAcMini, in my case also with some included in Imac.plist

from ssdtprgen.sh.

Wattages are like with my former SSDT, about 2,8-3,5W when idling. GB score seems a tad better, IPG showing all freqs like before. But I just saw that AICPUPMI - and HWMonitor - still do not show all P-states:
AICPUPMI: CPU P-States [ 12 13 23 29 (34) 36 37 ]
Arrrg! With the SSDT originally provided by Balamut all states were shown, even if this SSDT is technically incorrect. So - still not quite there?

from ssdtprgen.sh.

If you can try this:
vanilla fakesmc
ssdtPRGen12.7.sh -w 3
run console with AICPUPMI filter
and see steps
then run Luxmark 2.1 and change in it value for CPU and Gpu and sample scene test also use realtime for GPU (openCL bug is there but never mind)
You should see same wattage and maybe all steps after these passes

Ps

IPG and HW should start and stuck to 34 also in idle in your case..but steps are there and wattage is fine

from ssdtprgen.sh.

Sorry, but still doesn't work 100%. So, in essence (for me at least):

1. ssdtPRGen will ONLY work (and only partial in my case) if the stepdict from MacMini6.2 is used
2. And even then, CPU PM still seems limited, not all P-States shown, and MSR_PKG_C3_RESIDENCY is still ZERO.

So I ask for the last time before completely giving up on this issue (and start saving for a real mac bc this is getting soooo annoying):

Any idea what to do about this? I absolutely have no idea what else I can do to make this work.

from ssdtprgen.sh.

I started over. Used Clover. Installed via rampagedev guide. Had to do a fair bit of Clover hacking (his clover guide is just a starting point). THEN, using the latest ssdtPRGen with -w 3 and -turbo 4200 (overclocked to 4.2Ghz). Then the MOST important parts was to take the stock AICPUPMI module and patch BOTH patches from this tool: Hackintosh Vietnam Tool.pkg into it.

When I did that I got my 4.2Ghz Core i7-4960x to work very well on a Gigabyte x79 up4 with bios F5.

I almost gave up, but the combo of 10.9.2, clover, & Hackintosh Vietnam Tool got me working.

from ssdtprgen.sh.

Hi Fabio, thanks a lot for the hint! OK so I got this tool, but what specific patches must I apply? There are lots of them ...

from ssdtprgen.sh.

from ssdtprgen.sh.

Mmmm does not seem to work :/ So, when I do these two patches, the following happens:

AICPUPMI: MSR_PMG_CST_CONFIG_CONTROL.(0xE2) : 0x400 (was 403 before)
AICPUPMI: MSR_PKG_C2_RESIDENCY.......(0x60d) : 0x0
AICPUPMI: MSR_PKG_C3_RESIDENCY.......(0x3f8) : 0x0
AICPUPMI: MSR_PKG_C6_RESIDENCY.......(0x3f9) : 0x0

So all Residencies are now at "0". P-States, however are limited as before.

So what do I miss? So how did you inject the MacMini Stepdict (if at all): 1) by using the patched FakeSMC or 2) by using X79X86PlatformPlugin or 3) ???

from ssdtprgen.sh.

Or do you use any related additional clover settings? At the moment I have no patches set in clover at all.

from ssdtprgen.sh.

if you have an unlocked MB firmware you do not need to patch with Patch AICPUPM
Maybe the second option is useful for you, but only if you have some unknown cpu error in system log

from ssdtprgen.sh.

Well, I should have unlocked BIOS. (R4E, BIOS 4804) So if I restore AICPUPM I get my MSR values as before, but of course still no C3 Residency and limited P-States. Also tried the IVy-E patch alone, but that did not seem to change anything.

So I am out of luck (and ideas) now ... seems like this will never work properly - at least with me. :(((

from ssdtprgen.sh.

could you post your best Pstates results?
Then, Have you followed my advice to use for few time Luxmark 2.1 to see lower states printed out?
In my case, I have a vanilla osx 10.9.x (x from 2 to 3) with stock AICPUPM and no macmini patch
and i have all Pstates printed with latest Pike's AICPUPMI, but frequency start from 30 if measured with IPG or HW..But all pstates are there.
I don't need of any AICPUPM patch because my cpu is a Xeon 2690 V2 (not a choice for new mac pro, but same family)

from ssdtprgen.sh.

Ahhh I think I know what at least caused parts of my issues - seems like the version of AICPUPMI I used had a problem. So what I did is recompile the kext by hand with the latest source, and look what I get now:

09.05.14 17:10:23,000 kernel[0]: AICPUPMI: CPU P-States [ (12) 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 ]

Much better! However, lower P-states (14-16) still seem missing. Also, C3 Residency is still zero - but not sure if this is actually true, maybe also a reporting error with AICPUPMI? And HWMonitor actually reported a multiplier of 158(!!!) for a short amount of time - ouch! So seems that all these readings should maybe taken with a big grain of salt.

from ssdtprgen.sh.

yes, sometimes it is difficult to see lower pstates but if you have patience to play with some different luxmark 2.1 test (only cpu only gpu realtime etc etc) you will see also pstates 14 15 16..trust me.
In my case c3 residency is not a real marker because I have it to 0 but all pstates and cstates are there
If i patch my bootloader (chamaleon with two lines suggested by pike), I see also value for c3 residency..but results are the same! :-)

Problems with hackintosh in my case are others.... ;-)

from ssdtprgen.sh.

From the start i thought you was using latest 3.3 aicpupmi..if I had undestand that you were using an old one, maybe yhou should have less headache with your rig! :-)

from ssdtprgen.sh.

Well, I thought I had used the latest AICPUPMI, but seems like I somehow accidentally used an older / corrupt version ... sigh, my bad! And after running my machine idle for an extended amount of time, I seem to get the formerly missing states as well.

So the only thing remaining is the C3 residency being Zero, (I cannot use the chameleon patch since I use clover) but like with your case, I also seem to get all C-states: AICPUPMI: CPU C3-Cores [ 0 1 2 3 4 5 6 7 8 9 10 11 ]

Therefore, can we say that the missing value for C3 residency is rather cosmetic / does really not seem to affect anything?

from ssdtprgen.sh.

In my case Yes, with or without C3 Residency printed out correctly I have same states during my tests

from ssdtprgen.sh.

So I think I leave it as it is now. And as my wattages go as low as <3W even with active OC, I think CPU PM should be working ;) Also GB Score is in line with what can be expected (about 24.5k) so also my OC seems to be working.

So in essence the most important parts to get all working on X79 /w 4930K are:

• use MacPro 6.1 SMBIOS
• but use stepdict from MacMini6.2, or multis will be locked! Can be done for example with a patched FakeSMC or the X79X86PlatformPlugin.kext (I would recommend the latter)
• generate SSDT with ssdtPRGen.sh by using correct max Turbo values (if OCing) and the "-w 3" flag (Ivy workaround)
• be SURE to use latest AICPUPMI v3.3 to verify (you may need to compile it yourself from source, bc since at least for me, the download on Pike's blog immediatly panicked my machine)

Ooookay, all in all I think we can finally close this .... thanks to everybody who helped me out!

from ssdtprgen.sh.

Can you share your AICPUPMI v3.3 kext? The one from Pike's blog also panicked on mine and don't feel like installing all building tools.

from ssdtprgen.sh.

Well, if Pike is fine with it, I can post my compiled version somewhere. So would that be OK?

from ssdtprgen.sh.

Sorry guys. I've been extremely busy, but of course!

from ssdtprgen.sh.

hi alphanull. why did you suggest to use x79x86platformplugin.kext instead of patched fakesmc.kext?

from ssdtprgen.sh.

Because then, you can update FakeSMC independently! For example, latest (unpatched) update gives you individual Readings per CPU (multi/freq) for example. Works well, at least on my side. Also it is a matter of "Separation of Concerns" imho, bc with a patched FakeSMC, you have 2 separate functionalities wrapped up in one kext. I like to have my stuff separated, therefore I also do not like what myHack does (i.e. wrapping ALL hack specific kexts into one). And the FakeSMC patch seems to do exactly the same as x79x86platformplugin, ie modifying stepdict, so that Pike's script works as intended.

So yeah, all in all you just need ONE of the two alternatives and maybe it is also just a matter of taste - other ppl might prefer to have as few additional kexts as possible.

from ssdtprgen.sh.