Unable to generate SSDT for Xeon x5560

[DocFreeman]

Hi Piker,

I've been unable to generate an SSDT for my Xeon for the past few months and have had zero success in writing my own (keep in mind I wrote a lot of the one I use on my laptop, back when ssdtPRGen wasn't around). I can see that the script no longer really supports Nehalem processors, but can you help me out considering that the older one supposedly did?

Thanks.

[Piker-Alpha]

Open ssdtPRGen.sh in the editor of your choice and make this change:

-gBusFrequency=100
+gBusFrequency=133

Save/close/exit and run: ./ssdtPRGen.sh -t 95 -f 2800 -turbo 3200 -lfm 1600 -l 8

Is that working for you?

[DocFreeman]

You know, I actually went in and did the bus editing when I first tried this 4 months ago, but I recently discovered that appleLPC was messing my powermanagment (meaning it might have actually worked). I shall try your arguments later today.

[DocFreeman]

It complains that it doesn't recognize the CPU. I tried editing the script to remove the error checking, but I'm not sure I did it right.

[DocFreeman]

So after replacing the specifics of an Sandy Bridge Xeon in the script and being extra thorough with arguments, I came up with this:

~/ssdtPRGen.sh -t 95 -f 2800 -turbo 3200 -lfm 1600 -l 8 -w 0 -c 0 -p 'E5-2660' -b Mac-7BA5B2794B2CDB12 -m Macmini5,3

Where 'E5-2660' is the replaced processor.

This was the resulting code:
http://pastebin.com/VhH2FeuS

I got a kernel panic after putting it in /extra. Thoughts?

[Piker-Alpha]

Let's start with the arguments. I think that you can drop the -l, -w, -c, -b and -m arguments. Making it a little less complex to fire up the script. Also. The bus frequency is not right. 100 MHz wasn't supported until the first Core processors were introduced. As a result the P-States are also wrong.

Do you happen to have a ACPI table with _PSS and _CST objects in it?

[DocFreeman]

I uploaded the wrong SSDT. I did remember to change the bus frequency to 133mhz, and this pastebin link is the one I'm currently using. No more KPs (I edited something in Chameleon), though my geekbench score dropped by 4000. I assume it's still not correct.

http://pastebin.com/9xMcJ1WH

I agree that a lot of the arguments are superfluous though, the script takes care of things for the most part (well done). I have no idea where my I put the last ACPI I generated so I guess I'll make a new one. Thanks.

[Piker-Alpha]

ssdtPRGen.sh v14.5 is now available for download. This version supports -bclk 133 and thus you won't have to change the script anymore. The power, control and status data (integers) are also new/changed, but I need to verify the power values with your factory SSDT from Windows/Linux/OS X

[DocFreeman]

I ran the script, but the processor was still "Unknown". I went back in and replaced a Sandy Bridge processor again.

Here's my ACPI table, Factory SSDT, dumped ioreg, and edited SSDT: https://drive.google.com/folderview?id=0B6gwX98HtRRPOTNtQUtjX0hvbm8&usp=sharing

Rebooting to test now.

Edit: No change. SMC monitor reports no P or C states (apparently it's not fully compatible with nehalem but still) and geekbench is off by 7000 points.

[Piker-Alpha]

Correct. Your x5560 processor won't be recognised by ssdtPRGen.sh, but you can still generate a SSDT for it (by using arguments).

What I didn't know was that you have a MacPro3,1 with two processors in it, in which case argument -l 8 is wrong. You want -l 16, or don't use -l but you figured that out already.

I also checked the C-States and it supports only two so try this:

    Method (ACST, 0, NotSerialized)
    {
        Return (Package (0x04)
        {
            One,
            0x02,
            Package (0x04)
            {
                ResourceTemplate ()
                {
                    Register (FFixedHW,
                        0x01,               // Bit Width
                        0x02,               // Bit Offset
                        0x0000000000000000, // Address
                        0x01,               // Access Size
                        )
                },
                One,
                One,
                0x03E8
            },

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

You should see no errors related to ACPI when you boot in verbose mode.

[DocFreeman]

It really doesn't matter what arguments I use, the script will say it doesn't recognize my processors and throw its hands up. Hence the editing. The new argument does work though, so thanks for that. I've subbed the new C states in.

However, I don't think I've got speedstep yet (my geekbench is still low, etc.) Additionally, I think my system actually supports C3 because I remember seeing it in the BIOS somewhere. Anyway, I have this in my DSDT as of now, as well as Dropssdt=yes in Chameleon. Could it be conflicting with the SSDT?

Scope (_PR)
{
    Processor (CPU0, 0x00, 0x00001010, 0x06) {}
    Processor (CPU1, 0x01, 0x00001010, 0x06) {}
    Processor (CPU2, 0x02, 0x00001010, 0x06) {}
    Processor (CPU3, 0x03, 0x00001010, 0x06) {}
    Processor (CPU4, 0x04, 0x00001010, 0x06) {}
    Processor (CPU5, 0x05, 0x00001010, 0x06) {}
    Processor (CPU6, 0x06, 0x00001010, 0x06) {}
    Processor (CPU7, 0x07, 0x00001010, 0x06) {}
    Processor (CPU8, 0x08, 0x00001010, 0x06) {}
    Processor (CPU9, 0x09, 0x00001010, 0x06) {}
    Processor (CPUA, 0x0A, 0x00001010, 0x06) {}
    Processor (CPUB, 0x0B, 0x00001010, 0x06) {}
    Processor (CPUC, 0x0C, 0x00001010, 0x06) {}
    Processor (CPUD, 0x0D, 0x00001010, 0x06) {}
    Processor (CPUE, 0x0E, 0x00001010, 0x06) {}
    Processor (CPUF, 0x0F, 0x00001010, 0x06) {}
}

[DocFreeman]

Oh and just in case it wasn't clear: This is not a Mac Pro. It's a Lenovo ThinkStation D20 with Xeon processors. I only used that SMBIOS because it was the closest to my config.

Edit: I am stupid. 3,1 was the Westmere Mac Pro. I've changed to 4,1 with no improvement. Chameleon with p and c states enabled gets 16000 in geekbench 3 compared with the 9000 I get when using the SSDT.

[Piker-Alpha]

Yes. You still need to use the arguments, but at least it's one less now.

I also know that Chameleon injects the P-States and the C-States as _PSS and _CST objects, but the name of the ACPI objects shouldn't really matter. I mean APSS and ACST should be fine. The problem is most likely the contents of the ACST object.

I guess that you are booting now with Chameleon's P/C-State generation, and then you can extract the ACPI tables with help of: sudo /usr/local/bin/acpiTableExtract That gives you easy access to the ACPI tables in /tmp/. You can then compare the SSDT with that of what ssdtPRGen.sh creates. So what are the differences.

p.s. I understand that. No need for Chameleon with a real Mac Pro ;)

[DocFreeman]

Here are the ACPI tables: http://pastebin.com/8FLnaraP
It is rather beyond me to compare the tables to the SSDT though... A little help?

[Piker-Alpha]

I only see APIC.dsl there. I need your DSDT and SSDT tables.

[DocFreeman]

My bad, here they are: https://drive.google.com/open?id=0B6gwX98HtRRPUWwxUG52OFc3NmM&authuser=0

[Piker-Alpha]

Ok. Now I see the DSDT and two factory SSDT's and the generated SSDT for power management. And there are a couple of things that I don't understand. First I see this in your boot.log

CPU: NoCores/NoThreads: 4/8

Meaning that Chameleon only detects one processor. Not two. And then generating P/C-States should fail, simply because of this limitation.

The next thing that I see is this:

LoadDrivers: Loading from [/Extra/Extensions.mkext]
Read HFS+ file: [hd(0,3)/Extra/Extensions.mkext] 4096 bytes.
Read HFS+ file: [hd(0,3)/Extra/Extensions.mkext] 433816 bytes.

Why? I mean. Mavericks will not create a new Extensions.mkext file but Chameleon is still loading it. Rather strange.

Can you also add the SSDT that Chameleon created for you with P/C-State generation?

[DocFreeman]

Where does Chameleon store the generated SSDT? Because I uploaded all of the ones that were in /tmp. Also, I have no idea what's going on with the CPUs. The second one should definitely be active, and I see some evidence that it is from my ioreg (available here: https://drive.google.com/folderview?id=0B6gwX98HtRRPOTNtQUtjX0hvbm8&usp=sharing)

And the double mkext loading is really strange as well. I have no idea what that's about...

I can't find references to either of these events occurring anywhere in my log files (console, dmesg, etc).

[DocFreeman]

HWsensors also claims that only one CPU is working but it does reach 3.07ghz. Additionally, my Cinebench score is about half of what it should be, indicating that you are right. I will continue looking into this.

[Piker-Alpha]

Chameleon injects the power management SSDT in system memory (with the P/C-State generation options enabled) so you need to boot, run acpiTableExtract and then look in /tmp/ for the files.

The reference of the mkext and CPU detection error can be found in your boot.log You need a tool to dump the data, but I have no idea what that name is. I never used it.

Simply remove the .mkext file(s) because that should be old junk by now. Not used anymore.

[DocFreeman]

Ok, now I'm really confused. I get that the SSDT and other files are stored in RAM and subsequently dumped by acpiTableExtract to /tmp. I uploaded the DSDT and SSDT files I found in there, as well as the APIC file that was there. But there is no ACPI tables file.

I'll look into retrieving my boot.log and get rid of the mkext.

[DocFreeman]

I'm also reading through this thread but it's not exactly light reading. http://www.insanelymac.com/forum/topic/196771-ga-ex58-and-ga-x58a-dsdt-native-power-management-modifications/

[Piker-Alpha]

"ACPI tables" (plural) is referring to the extracted tables. Not to one specific table.

What I would like you to do is that you boot into Windows or Linux – if possible – and extract the original (vanilla/untouched) tables, because what you uploaded was with Chameleon and that is not what I need to help you.

[DocFreeman]

Just installed a couple RDIMMs, which shouldn't change anything (right)?

Here are my full ACPI tables: https://drive.google.com/open?id=0B6gwX98HtRRPa25sbWFoTWlFbDQ&authuser=0

Sorry about the confusion, Everest64 doesn't allow for the export of the whole table at once.

[Piker-Alpha]

Thank you. That's more like it. The first thing that I noticed is that the factory _PSS object lacks turbo frequencies:

Package(6) {0x00000AEA, 0x00017318, 0x0000000A, 0x0000000A, 0x00000016, 0x00000016}, 
Package(6) {0x00000AE9, 0x00017318, 0x0000000A, 0x0000000A, 0x00000015, 0x00000015}, 
Package(6) {0x00000A64, 0x00013498, 0x0000000A, 0x0000000A, 0x00000014, 0x00000014}, 
Package(6) {0x000009DF, 0x00011558, 0x0000000A, 0x0000000A, 0x00000013, 0x00000013}, 
Package(6) {0x0000095A, 0x0000E678, 0x0000000A, 0x0000000A, 0x00000012, 0x00000012}, 
Package(6) {0x000008D5, 0x0000CF08, 0x0000000A, 0x0000000A, 0x00000011, 0x00000011}, 
Package(6) {0x00000850, 0x0000A7F8, 0x0000000A, 0x0000000A, 0x00000010, 0x00000010}, 
Package(6) {0x000007CB, 0x00009858, 0x0000000A, 0x0000000A, 0x0000000F, 0x0000000F}, 
Package(6) {0x00000746, 0x000088B8, 0x0000000A, 0x0000000A, 0x0000000E, 0x0000000E}, 
Package(6) {0x000006C1, 0x00006D60, 0x0000000A, 0x0000000A, 0x0000000D, 0x0000000D}, 
Package(6) {0x0000063C, 0x000061A8, 0x0000000A, 0x0000000A, 0x0000000C, 0x0000000C}

That is 1600-2800MHz, but the next update of ssdtPRGen.sh will generate this data:

/* High Frequency Modes (turbo) */
Package (0x06) { 0x0D02, 0x017318, 0x0A, 0x0A, 0x0019, 0x0019 },
Package (0x06) { 0x0C80, 0x017318, 0x0A, 0x0A, 0x0018, 0x0018 },
Package (0x06) { 0x0BFA, 0x017318, 0x0A, 0x0A, 0x0017, 0x0017 },
Package (0x06) { 0x0B75, 0x017318, 0x0A, 0x0A, 0x0016, 0x0016 },
/* High Frequency Modes (non-turbo) */
Package (0x06) { 0x0AF0, 0x017318, 0x0A, 0x0A, 0x0015, 0x0015 },
Package (0x06) { 0x0A6A, 0x012DB6, 0x0A, 0x0A, 0x0014, 0x0014 },
Package (0x06) { 0x09E5, 0x010E87, 0x0A, 0x0A, 0x0013, 0x0013 },
Package (0x06) { 0x0960, 0x00D6C0, 0x0A, 0x0A, 0x0012, 0x0012 },
Package (0x06) { 0x08DB, 0x00BE00, 0x0A, 0x0A, 0x0011, 0x0011 },
Package (0x06) { 0x0855, 0x009259, 0x0A, 0x0A, 0x0010, 0x0010 },
Package (0x06) { 0x07D0, 0x007F49, 0x0A, 0x0A, 0x000F, 0x000F },
Package (0x06) { 0x074B, 0x006DF4, 0x0A, 0x0A, 0x000E, 0x000E },
Package (0x06) { 0x06C5, 0x005028, 0x0A, 0x0A, 0x000D, 0x000D },
/* Low Frequency Mode */
Package (0x06) { 0x0640, 0x004386, 0x0A, 0x0A, 0x000C, 0x000C }

Which gives you 1600-3330 MHz (much cleaner values) and thus this was the first thing that I fixed. Next up. C-States...

[DocFreeman]

So I can just copy and paste this into the SSDT, right? I'll report back with results in a bit.

Any thoughts on why my second processor is ignored? Without it my machine is a bit neutered.

[Piker-Alpha]

Yes, you can with this:

Name (APSN, 0x04)
Name (APSS, Package (0x0E)
{
// Put the data here
})

About the second processor. Not really, but try this first.

[DocFreeman]

I can't even generate one with the newest version of ssdtPRGen. I looked in the script and it uses the -a argument to identify the processor. It then complains if I put in the processor name (x5560) because it is longer than 3 characters.

I'll add the code to an old one I had it generate 2 weeks ago.

[Piker-Alpha]

You want -p because -a is used to change/setup the ACPI processor names (CPU0-CPUF) and I myself use this for testing:

./ssdtPRGen.sh -p x5560 -bclk 133 -f 2800 -turbo 3330

[DocFreeman]

Still complains that the processor is unrecognized. I've tried feeding it everything it asks for except for cores (how do you tell it the number of cores? I can't find that anywhere in the script):

Override value: (-t) maximum TDP, now using: 95 Watt!
Override value: (-f) clock frequency, now using: 2800 MHz!
Override value: (-turbo) maximum (turbo) frequency, now using: 3200 MHz!  
Override value: (-lfm) low frequency mode, now using: 1600!
Override value: (-bclk) frequency, now using: 133 MHz!
Override value: (-l) number of logical processors, now using: 16!

System information: Mac OS X 10.9.2 (13C64)
Brandstring 'Intel(R) Xeon(R) CPU X5560 @ 2.80GHz'

Error: Unknown processor model ...
       Visit http://ark.intel.com to gather the required data:
       Processor Number
       TDP
       Low Frequency Mode (use AppleIntelInfo.kext)
       Base Frequency
       Max Turbo Frequency
       Cores
       Threads
Aborting ...
Done.

~/ssdtprgen.sh -p x5560 -t 95 -f 2800 -turbo 3200 -lfm 1600 -bclk 133 -l 16

I can't define the number of cores using any existing arguments.

As to the SSDT I edited, it seems to be working. However, the highest speed available at the moment is 2.8ghz, much lower than the 3.2ghz maximum of this processor.
Note: I think you assumed that my processor could run at 3.3ghz, but ark.intel (and many other sources) claim a maximum of 3.2.

[Piker-Alpha]

We now have a new Beta version (v15.7) available for download, with lots of changes. Most of them specifically for your setup.
One of the changes allows you to use a custom file called: ~/Library/ssdtPRGen/Data/User Defined.cfg
And this is what I am using for my test runs:

#
# This file includes the user defined processor models:
#
# Processor Number, Max TDP, Low Frequency Mode, Clock Speed, Max Turbo Frequency, Cores, Threads, bridge type, bus frequency 
#
# Notes:
#
#        A "low frequency mode" of 0 means that the frequency is unconfirmed (use AppleIntelInfo.kext).
#        Processors without turbo support should set Max Turbo Frequency equal to the Clock Speed.
#
#
# Please report missing processor data at: https://github.com/Piker-Alpha/ssdtPRGen.sh/issues
#

gUserDefinedCPUList=(
X5560,95,1600,2800,3200,8,16,2,133
)

Run ssdtPRGen.sh with:

~/ssdtPRGen.sh -p X5560

Just one single argument.

Just download/run the one from the Beta branch, instead of the "master" branch ;)

[DocFreeman]

Thank you so much for this, it worked perfectly! It's amazing to see how much this script has progressed over the years.

I ran it, and here's the relevant output (note that the max TDP field is blank even though it was defined in the config file):

    Scope (\_PR_.CPU0)
    {
        Method (_INI, 0, NotSerialized)
        {
            Store ("ssdtPRGen version....: 15.7 / Mac OS X 10.9.2 (13C64)", Debug)
            Store ("target processor.....: x5560", Debug)
            Store ("running processor....: Intel(R) Xeon(R) CPU X5560 @ 2.80GHz", Debug)
            Store ("baseFrequency........: 1600", Debug)
            Store ("frequency............: 2800", Debug)
            Store ("busFrequency.........: 100", Debug)
            Store ("logicalCPUs..........: 16", Debug)
            Store ("maximum TDP..........: ", Debug)
            Store ("packageLength........: 13", Debug)
            Store ("turboStates..........: 0", Debug)
            Store ("maxTurboFrequency....: 2800", Debug)
            Store ("machdep.xcpm.mode....: 0", Debug)
        }

        Name (APLF, Zero)
        Name (APSN, Zero)
        Name (APSS, Package (0x0D)
        {
            /* High Frequency Modes (non-turbo) */
            Package (0x06) { 0x0AF0, 0x000000, 0x0A, 0x0A, 0x1C00, 0x1C00 },
            Package (0x06) { 0x0A8C, 0x000000, 0x0A, 0x0A, 0x1B00, 0x1B00 },
            Package (0x06) { 0x0A28, 0x000000, 0x0A, 0x0A, 0x1A00, 0x1A00 },
            Package (0x06) { 0x09C4, 0x000000, 0x0A, 0x0A, 0x1900, 0x1900 },
            Package (0x06) { 0x0960, 0x000000, 0x0A, 0x0A, 0x1800, 0x1800 },
            Package (0x06) { 0x08FC, 0x000000, 0x0A, 0x0A, 0x1700, 0x1700 },
            Package (0x06) { 0x0898, 0x000000, 0x0A, 0x0A, 0x1600, 0x1600 },
            Package (0x06) { 0x0834, 0x000000, 0x0A, 0x0A, 0x1500, 0x1500 },
            Package (0x06) { 0x07D0, 0x000000, 0x0A, 0x0A, 0x1400, 0x1400 },
            Package (0x06) { 0x076C, 0x000000, 0x0A, 0x0A, 0x1300, 0x1300 },
            Package (0x06) { 0x0708, 0x000000, 0x0A, 0x0A, 0x1200, 0x1200 },
            Package (0x06) { 0x06A4, 0x000000, 0x0A, 0x0A, 0x1100, 0x1100 },
            /* Low Frequency Mode */
            Package (0x06) { 0x0640, 0x000000, 0x0A, 0x0A, 0x1000, 0x1000 }
        })

        Method (ACST, 0, NotSerialized)
        {
            Store ("Method CPU0.ACST Called", Debug)
            Store ("CPU0 C-States    : 13", Debug)

            /* Low Power Modes for CPU0 */
            Return (Package (0x05)
            {
                One,
                0x03,
                Package (0x04)
                {
                    ResourceTemplate ()
                    {
                        Register (FFixedHW,
                            0x01,               // Bit Width
                            0x02,               // Bit Offset
                            0x0000000000000000, // Address
                            0x01,               // Access Size
                            )
                    },
                    One,
                    Zero,
                    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
                }
            })
        }
    }

Rebooting now to see what we can see.

I'd like to run this by you, as I think it's related to my speedstepping issues: I'm getting audio stutters while using HDMI audio through my GPU. At first, I thought it was VoodooHDA, but after getting rid of it completely the issue persisted. The error is logged in the console as such:

    12/11/14 10:16:18.000 PM kernel[0]: IOAudioStream[0xffffff802d7d8e00]::clipIfNecessary() -adjusting clipped position to (6e49,1318)
    12/11/14 10:17:03.000 PM kernel[0]: IOAudioStream[0xffffff802d7d8e00]::clipIfNecessary() - Error: attempting to clip to a position more than one buffer ahead of last clip position (6ef3,1dc4)->(6efa,dc0).

Using my limited GoogleFu, I was able to find out that the one commonality among users suffering from IOAudioStream errors was mention of the CPU, eliminating my fear of IRQ errors (which I am still not sure whether my machine is suffering from). It seems C-states and HPET timing might have something to do with it. I know HPET is loaded and working, but my machine has no HPET bios settings so I don't know whether it's 64bit or not. Audio is more consistent when the mouse is moving and I'm doing something which would support the theory that lower processor states are causing a problem. I'll see if the new SSDT helps things and report back.

[DocFreeman]

No change: Processor is still limited to 2800mhz according to iStat menus. The geekbench is off as well so I'm assuming it's right.
The only P-states I see are:
2800
2100
1600
I can't monitor P-states or C-states any other way on Nehalem.
The IOAudioStream clipping is still present as well.

[Piker-Alpha]

Thanks. Yeah we made some progress. Thanks to people like you who ask for improvements. I mean. If the script wasn't used this much then nothing would have changed since my personal need for changes is close to zero. Anyway. I have now set TDP to 90 and that's what I see. Using: -p X5560 -t 55 also works here. Do you see any messages related to TDP?

About the audio stutter. You had a good working SSDT and with that there's no stutter? If not then it is clearly the SSDT.

About monitoring P-States. A self compiled version of AppleIntelInfo.kext should work. Note that I don't use iStat and I have no idea if it picks up Turbo states or not.