Can't Get Speedstep to Work (i5-750 @ 3.2Ghz, Asus P7P55D)

[eradicator006]

I'm not sure why it's not working since you're using the same motherboard and processor as jca126. You mind uploading your SSDT?

Dil83

EDIT: I noticed that jca126 overclocked by changing the BCLK which is also what I had to do in order for my overclock to work properly in OS X. For some reason OS X won't allow my Multiplier to go beyond x25. I'm now stable at 4.0Ghz. My motherboard has an auto overclock function in the BIOS, but it changes the Multiplier to reach the faster speed so I'm unable to utilize it.

Here is the modified SSDT. I overclocked by changing my base clock. It's at 200 with an 18 multiplier.

One other thing. I am now using imac11,1. I was original on macpro4,1 so I changed to imac11,1. That didn't change anything.

Speedstep is enabled in my bios. Turbo mode is disabled (I don't want it going higher than 3.6ghz). Multiplier is manually set to 18. BCLK is set to 200.

EDIT:
When using the SSDT I am seeing "SSDT-1 ACPI table not found" in the chameleon messages. In DSDT-SE when I extract the table SSDT-1, it is my custom ssdt file.

 

[Dil83]

Here is the modified SSDT. I overclocked by changing my base clock. It's at 200 with an 18 multiplier.

One other thing. I am now using imac11,1. I was original on macpro4,1 so I changed to imac11,1. That didn't change anything.

Speedstep is enabled in my bios. Turbo mode is disabled (I don't want it going higher than 3.6ghz). Multiplier is manually set to 18. BCLK is set to 200.

EDIT:
When using the SSDT I am seeing "SSDT-1 ACPI table not found" in the chameleon messages. In DSDT-SE when I extract the table SSDT-1, it is my custom ssdt file.

What happens when you extract the SSDT.aml using DSDTSE while using your custom SSDT.aml? Is it different than the SSDT-1.aml when you extract it? What did you name your SSDT? Chimera is capable of loading several SSDT tables using the naming scheme SSDT.aml, SSDT-1.aml, SSDT-2.aml, SSDT-3.aml, etc.....
So if you named it SSDT-1.aml then it will be loading and replacing the corresponding table present in the BIOS instead of loading and replacing the SSDT.aml table like it should.

Dil83

 

[Dil83]

You could try to use Revogirl's SSDT generation script and see how it compares the one you customized. The good thing about Revogirl's script is that it also includes the power values for each P-State rather than setting each to zero, but as far as I understand OS X ignores these values anyway.

Here's the link to her script: http://www.tonymacx86.com/ssdt/56186-revogirl-ssdt-generation-script.html

Instructions are on post #4

BTW, your SSDT looks great, but I thought this might be helpful.

Dil83

 

[eradicator006]

What happens when you extract the SSDT.aml using DSDTSE while using your custom SSDT.aml? Is it different than the SSDT-1.aml when you extract it? What did you name your SSDT? Chimera is capable of loading several SSDT tables using the naming scheme SSDT.aml, SSDT-1.aml, SSDT-2.aml, SSDT-3.aml, etc.....
So if you named it SSDT-1.aml then it will be loading and replacing the corresponding table present in the BIOS instead of loading and replacing the SSDT.aml table like it should.

Dil83

Now I am using the custom SSDT and when I extract SSDT in dsdtse it shows my custom file. I'm not sure why it didn't work right before. I had dropssdt in my chameleon file.

I did get things partially working. I have 3 power states now. 1.8ghz, 3.2ghz and 3.6ghz. I had to rename the cpu names in the ssdt from cpu0, cpu1, cpu2, cpu3 to P001, P002, P003 and P004. That's what's in my dsdt and that is also how the dsdt is that you can download from this site.

I'll try that script that automatically generates and see what happens.

Thanks for all the tips.

EDIT:
Maybe it's not working at all. It's kind of strange. MSRDumper shows this over and over:

MSRDumper CoreMulti(0)
MSRDumper PStatesReached:

The cpu speed changes between 3 speeds though.

 

[Dil83]

Now I am using the custom SSDT and when I extract SSDT in dsdtse it shows my custom file. I'm not sure why it didn't work right before. I had dropssdt in my chameleon file.

I did get things partially working. I have 3 power states now. 1.8ghz, 3.2ghz and 3.6ghz. I had to rename the cpu names in the ssdt from cpu0, cpu1, cpu2, cpu3 to P001, P002, P003 and P004. That's what's in my dsdt and that is also how the dsdt is that you can download from this site.

I'll try that script that automatically generates and see what happens.

Thanks for all the tips.

EDIT:
Maybe it's not working at all. It's kind of strange. MSRDumper shows this over and over:

MSRDumper CoreMulti(0)
MSRDumper PStatesReached:

The cpu speed changes between 3 speeds though.

You're right, ASUS uses a different processor naming scheme in their ACPI tables than Gigabyte uses, but originally have the CPU0, CPU1, etc.... as an alias for each corresponding processor in the DSDT. When the DSDT is patched one of the things that is removed is the processor aliases because they caused a problem with older versions of OS X. From what I understand, the aliases are no longer a problem with the newer versions of OS X. What I did is actually renamed all my processor names in the DSDT to CPU0, CPU1, etc... just to make it more like a genuine Mac Pro 5,1 which is what my hardware most closely matches.

That brings up a bigger question as to why the SSDT worked for jca126? He must still have the processor aliases in his patched DSDT, or is not using one.

From what I've read, MSRDumper actually dropped support for the first generation of the Intel Core i series processors, and is designed to work with the second generation Intel Sandy Bridge processors, so that's why it won't show you anything. It doesn't work for me either. I also can only see 3 P-States being utilized when using HWMontior.app, but that doesn't necessarily mean that it's not using more of the P-States in between that the HWMonitor.app just doesn't pick up on fast enough. I figured that this is better than only seeing the lowest and highest P-State when letting Chimera Generate the P-States. I wish I were able to see all of the P-States that are actually being used, but from what I understand, support was dropped for the first gen processors because MSDumper actually affected what P-States were being utilized and therefore could not give an accurate reading.

Dil83