DSDT - Vanilla Speedstep - Generic Scope (_PR)

[Master Chief]

Thank you.

Anyways, TYPE value is 0x80000000 here, so no changes at all.

Ah you've seen this Name (TYPE, 0x80000000) and expect it to stay like that. Newsflash it will be initialized by OSPM but bits 5, 6 and 7 won't be set for the first CPU (that is also why you see checks for 0x20 in _CST).

 

My PSS contains 4 states, now the question is why the cpu frequency only changed between the highest and lowest although cpu-i shows 7 states here:

<snip />

Yeah, that can be misleading: CPU-i shows calculated values, not the values you've added. This data however can be pretty helpful in combination with the P-State Calculator.

 

Also, I'm afraid that I had bad news for you. You may have fixed the KP, but you apparently still only have two functional P-States. More work to be done so to speak.

[yeehaa]

I'm here to confirm that this works for me, no more KP.

Thanks THe King a lot for the tip.

 

My PSS contains 4 states, now the question is why the cpu frequency only changed between the highest and lowest although cpu-i shows 7 states here:

 

you can add all the pstates (and just the _PSS) to your dsdt and will get perfect switching between them. i had only three in my ssdt, but added 6 more to my dsdt and it is working alright

[oldnapalm]

Ah you've seen this Name (TYPE, 0x80000000) and expect it to stay like that. Newsflash it will be initialized by OSPM but bits 5, 6 and 7 won't be set for the first CPU (that is also why you see checks for 0x20 in _CST).

 

Thanks man, now I (finally) got it.

It's working just adding CST and setting SMproductname as "MacPro3,1" in smbios. I had the stuttering sound problem, but fixed removing IRQ from PIC and TMR (workaround, you name it).

 

One last question: my DSDT has OperationRegion (STBL, SystemMemory, 0x7FF8E0D0, 0x01D2) under Processor, so I woudn't need to add calculated PSS, right? But if I don't it looks like I have only 2 working P-states (2 values under PerformanceStateArray), and if I add calculated values (took from CPU-i running in Leopard with VoodooPower) I have 4. Does it mean PSS from SSDT are wrong?

 

Thank you FormerlyKnownAs for the topic, you were right, maybe if I had took the time to read the whole thread I wouldn't need to ask and create more pollution, sorry for that.

[Master Chief]

Thanks man, now I (finally) got it.

No worries. We're all here to learn new stuff after all.

 

It's working just adding CST and setting SMproductname as "MacPro3,1" in smbios. I had the stuttering sound problem, but fixed removing IRQ from PIC and TMR.

Welcome to the club

 

One last question: my DSDT has OperationRegion (STBL, SystemMemory, 0x7FF8E0D0, 0x01D2) under Processor, so I woudn't need to add calculated PSS, right? But if I don't it looks like I have only 2 working P-states (2 values under PerformanceStateArray), and if I add calculated values (took from CPU-i running in Leopard with VoodooPower) I have 4. Does it mean PSS from SSDT are wrong?

That's up to you: you may want to add a customized _PSS object, one with four P-States in it, but you may skip this step when you're happy with two. Let's just say that the _PSS from your SSDT is a bit more "limited".

 

you can add all the pstates (and just the _PSS) to your dsdt and will get perfect switching between them. i had only three in my ssdt, but added 6 more to my dsdt and it is working alright

He wrote: "My PSS contains 4 states..." and thus he already has a _PSS object (right?) but it is hard to tell without having the actual DSDT at hand.

[dong]

He wrote: "My PSS contains 4 states..." and thus he already has a _PSS object (right?) but it is hard to tell without having the actual DSDT at hand.

I did not put the _PSS object into DSDT. It's in SSDT and I guess there is no need to move it to DSDT. The 4 states can be observed in IORegistry, with the values (corresponding to 2000, 1667, 1333 and 1000MHz) from SSDT. If it helps, here are the DSDT and related SSDTs:DSDT_SSDT.zip

I modified my last post. The IRQ modification did not solve my KP problem. The first reboot happened to be a rare good case that system run well. Following reboots not work. Before KP, the console has lots of such messages (content in () varies):

9/30/09 1:34:10 PM	com.apple.launchd[1]	(com.apple.locationd) Throttling respawn: Will start in 1 seconds
9/30/09 1:34:10 PM	com.apple.launchd.peruser.501[146]	(com.apple.PreferenceSyncAgent) Throttling respawn: Will start in 2 seconds
9/30/09 1:34:10 PM	com.apple.launchd.peruser.501[146]	(com.apple.ReportCrash) Throttling respawn: Will start in 3 seconds

[yeehaa]

That's up to you: you may want to add a customized _PSS object, one with four P-States in it, but you may skip this step when you're happy with two. Let's just say that the _PSS from your SSDT is a bit more "limited".

 

 

He wrote: "My PSS contains 4 states..." and thus he already has a _PSS object (right?) but it is hard to tell without having the actual DSDT at hand.

 

yeah. but he had a complaint that they were not switchin properly and that he wanted all 7 of them.

[Brett Whinnen]

So the issue must be with a mis-match in the number of CSTATES I have in my SSDT compared to what ACPI_SMC is expecting to see? Would that be a fair call?

 

Anybody got a comment on that? That the CSTATES are not loaded because ACPI_SMC_Plugin is looking for a certain number of CSTATES in the SSDT (based on a model number) and if it gets a mismatch it doesn't load them?

 

I've attached my SSDT1.dsl for reference. Which has my laptops available CSTATES. Is there an easy way to identify which of those relates to which CSTATE?

 

SSDT1.dsl.zip

 

I'm currently running a MacBookPro5,1 as my model identifier, if I run a MacBookPro4,1 I get an issue with Pstates (as I only have 6 but it is expecting 9, still loads the 6 though), it still has the LPC based error for CSTATES but I do get a CState entry in the ACPI_SMC section of IOReg that says 'True'...

 

Thanks,

 

Brett

[Master Chief]

Anybody got a comment on that? That the CSTATES are not loaded because ACPI_SMC_Plugin is looking for a certain number of CSTATES in the SSDT (based on a model number) and if it gets a mismatch it doesn't load them?

I would say no, but let me change mine to a MacBookPro[4/5],1 and see what happens

 

Edit: Right. No problem when I use "MacBookPro5,1" data, but with "MacBookPro4,1" data I get:

 

"WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for P5K PRO with 4 p-states, using default stepper instead"

 

Note: Never mind the "P5K PRO" here because I replaced "MacBookPro4,1" in the Info.plist with "P5K PRO" (that's the beauty of doing stuff like this).

 

And I also don't have a CSTinfo property. This is however easily to explain since under: CtrlLoopArray -> PLimitDict -> MacBookPro4,1 there's a property called: num-states which is set to 9 while there's no limit for:

 

MacBook5,1

MacBook5,2

MacBookPro5,1

MacBookPro5,2

MacBookPro5,3

MacBookPro5,4

MacBookPro5,5

MacPro3,1

Macmini3,1

iMac9,1

 

The others with limited P-States are:

 

MacBookAir1,1 (4, 6 or 6 P-States)

MacBookAir2,1 (2, 3 or 4 P-States)

 

This is also what THe KiNG addressed in post #261.

 

I've attached my SSDT1.dsl for reference. Which has my laptops available CSTATES. Is there an easy way to identify which of those relates to which CSTATE?

Yes. Let's pick one from your DSDT and I'll add some comments to it:

Return (Package (0x02)
{
   0x01,  // Number of C-States
   Package (0x04)
   {
       ResourceTemplate ()
       {
           Register (FFixedHW, 
           0x00,  // Bit Width
           0x00,  // Bit Offset
           0x0000000000000000,  // Address
           ,)
       },

       0x01,  // C-State aka C1
       0x9D,  //  Latency in microseconds (worse case) to change C-State.
       0x03E8  // Average power consumption in milliwatt (per core).
   }
})

Make sure to (re)read post #46 and post #58

[Brett Whinnen]

I would say no, but let me change mine to a MacBookPro[4/5],1 and see what happens

 

Edit: Right. No problem when I use "MacBookPro5,1" data, but with "MacBookPro4,1" data I get:

 

"WARNING - ACPI_SMC_CtrlLoop::initCPUCtrlLoop - no sub-config match for P5K PRO with 4 p-states, using default stepper instead"

 

Note: Never mind the "P5K PRO" here because I replaced "MacBookPro4,1" in the Info.plist with "P5K PRO" (that's the beauty of doing stuff like this).

 

And I also don't have a CSTinfo property. This is however easily to explain since under: CtrlLoopArray -> PLimitDict -> MacBookPro4,1 there's a property called: num-states which is set to 9 while there's no limit for:

 

MacBook5,1

MacBook5,2

MacBookPro5,1

MacBookPro5,2

MacBookPro5,3

MacBookPro5,4

MacBookPro5,5

MacPro3,1

Macmini3,1

iMac9,1

 

The others with limited P-States are:

 

MacBookAir1,1 (4, 6 or 6 P-States)

MacBookAir2,1 (2, 3 or 4 P-States)

 

This is also what TheKing addressed in post #261.

 

Yeah got that bit already I modified the entry for MacBookPro4,1 and set number of states to 6 (from 9) and got rid of the error above.

 

Yes. Let's pick one from your DSDT and I'll add some comments to it:

Return (Package (0x02)
{
   0x01,  // Number of C-States
   Package (0x04)
   {
       ResourceTemplate ()
       {
           Register (FFixedHW, 
           0x00,  // Bit Width
           0x00,  // Bit Offset
           0x0000000000000000,  // Address
           ,)
       },

       0x01,  // C-State aka C1
       0x9D,  //  Latency in microseconds (worse case) to change C-State.
       0x03E8  // Average power consumption in milliwatt (per core).
   }
})

Make sure to (re)read post #46 and post #58

 

Now that helps, re-reading those posts now I'm looking further into things, I'd forgotten about those posts, specially #58.

 

The question of the day is looking at a couple where 3 C-states are defined, the latency is 0x01 for both C1 and C2, that doesn't seem very long at all... So would some other value change (which are only CFGD or PDCx) that would then determine which of the multiple C-States would be used?

 

Does CFGD ever change from the value set in the SSDT table?

 

Thanks for having a look!

[Master Chief]

...The question of the day is looking at a couple where 3 C-states are defined, the latency is 0x01 for both C1 and C2, that doesn't seem very long at all... So would some other value change (which are only CFGD or PDCx) that would then determine which of the multiple C-States would be used?

I can't help you with the first part of your question, but CFGD is more or less static (see below). And what I know about PDCx (or TYPE for ASUS boards) is that the value for the first CPU core is different – this to block it from entering higher C-States. You could verify this yourself, but it is a painstakingly slow process, trust me I've been there already. Anyway, it is bit 9 (0x0200) in your _CST that does this job:

If (And (CFGD, 0x0200))

The other bits/values can be found in the table in post #71

 

Does CFGD ever change from the value set in the SSDT table?

Not really. But the value depends on BIOS settings (where available). See also post #293 by keeza

 

Thanks for having a look!

You're welcome.

[FKA]

Thank you FormerlyKnownAs for the topic, you were right, maybe if I had took the time to read the whole thread I wouldn't need to ask and create more pollution, sorry for that.

 

No worries - glad you got it sorted

 

On another note - with Snow I haven't needed to edit APCI_SMC to get p-states and get rid of cst evaluation errors (using original method of adding ist and cst to DSDT).

 

OT - I have lost deep sleep though but I think this is as I was using slice's patched USB kext for 10.5.8 (and yes I have added EHCI patch to DSDT.)

 

D.

[Master Chief]

I continued my testing today, and this time I used MacPro4,1 data to find the following error in kernel.log:

 

ACPI_SMC_GPU_CtrlLoop::controlRegistered - unexpected control ID 16

 

The reason I got this error was because my model identifier is set to P5K PRO and thus there's nothing in AppleGraphicsPowerMangement.kext to match with. Enter a quick and dirty LegacyAGPM.kext (see attachments). Now my NVIDIA 9600GT (10de:0622) is recognized, and thus no more error. Oh and here's a handy link to lookup PCI vendor and device ID's.

 

Next thing is to work on a LegacyACPI_SMC_PlatformPlugin.kext – no more /S*/L*/Extensions hacks for me – to enable NVIDIA throttling since that now only works with MacPro4,1 And I am not going to use this identifier but the one of a MacPro3,1 instead.

LegacyAGPM.kext.zip

[harshw]

I have an i7 oc'ed to 3.5 GHz. Model identifier is set to MacPro 4,1.

 

I get this in the ACPI_SMC_Plugin

 

 

And of course my board being ASUS, I have the usual section for CPU

 

DefinitionBlock ("dsdt.aml", "DSDT", 1, "A1279", "A1279001", 0x00000001)

{

Scope (_PR)

{

Processor (P001, 0x01, 0x00000810, 0x06) {}

Alias (P001, CPU1)

Processor (P002, 0x02, 0x00000000, 0x00) {}

Alias (P002, CPU2)

Processor (P003, 0x03, 0x00000000, 0x00) {}

Alias (P003, CPU3)

Processor (P004, 0x04, 0x00000000, 0x00) {}

Alias (P004, CPU4)

Processor (P005, 0x05, 0x00000000, 0x00) {}

Alias (P005, CPU5)

Processor (P006, 0x06, 0x00000000, 0x00) {}

Alias (P006, CPU6)

Processor (P007, 0x07, 0x00000000, 0x00) {}

Alias (P007, CPU7)

Processor (P008, 0x08, 0x00000000, 0x00) {}

Alias (P008, CPU8)

Processor (P009, 0x09, 0x00000000, 0x00) {}

Alias (P009, CPU9)

Processor (P010, 0x0A, 0x00000000, 0x00) {}

Processor (P011, 0x0B, 0x00000000, 0x00) {}

Processor (P012, 0x0C, 0x00000000, 0x00) {}

Processor (P013, 0x0D, 0x00000000, 0x00) {}

Processor (P014, 0x0E, 0x00000000, 0x00) {}

Processor (P015, 0x0F, 0x00000000, 0x00) {}

Processor (P016, 0x10, 0x00000000, 0x00) {}

}

 

 

MSR tools running under 32bit 10.6 tells me the CPU runs at 3.5GHz. What is surprising is that idle temps are 44c ~ 45c. Granted I have a TRUE-120, but shouldn't they be higher ? I get temps of 43c ~ 44c under Windows, so not much of a difference. And my Windows idle is at 2000 MHz ( 12x mult )

 

 

So what's going on ? Does OSX idle at 3.5 GHz so efficiently that the temps are comparable to 2.0 GHz ? And do I have to replace the P-State array and create new C-states for the 3.5 GHz overclock ?

[Beerkex'd]

The reason I got this error was because my model identifier is set to P5K PRO and thus there's nothing in AppleGraphicsPowerMangement.kext to match with. Enter a quick and dirty LegacyAGPM.kext (see attachments). Now my NVIDIA 9600GT (10de:0622) is recognized, and thus no more error.

That's pretty cool, thanks!

I deleted the two other Nvidia IDs in the kext, and changed yours to 0612 to match my 9800GTX+ and it loads.

This ought to be more compatible than having my 9800GTX+ identified as an IGP (I use iMac9,1 for model identifier).

Do you know what the "control-id" corresponds to? GPU class/family?

And the thresholds, are they degrees centigrade or a percentage of something?

IOReg screenshot:

Next things is to work on a LegacyACPI_SMC_PlatformPlugin.kext – no more /S*/L*/Extensions hacks for me – to enable NVIDIA throttling since that now only works with MacPro4,1 And I am not going to use this identifier but the one of a MacPro3,1 instead.

Wow Good luck on that.

[THe KiNG]

So what's going on ? Does OSX idle at 3.5 GHz so efficiently that the temps are comparable to 2.0 GHz ? And do I have to replace the P-State array and create new C-states for the 3.5 GHz overclock ?

Well you have rev D0 on CPU, that is known as cooler then C0/C1.

Anyway I don't know how much trust you can have on MSRTools on temps...

There is a better tool for reading temps and fans Mark-i be aware that thread is in rusian and for snow only

If your sensor chip is Winbond W83667HG(check with Lavalys Everest) it should work with it.

[Master Chief]

That's pretty cool, thanks!

I deleted the two other Nvidia IDs in the kext, and changed yours to 0612 to match my 9800GTX+ and it loads.

This ought to be more compatible than having my 9800GTX+ identified as an IGP (I use iMac9,1 for model identifier).

IGP is the Internal Graphics Processor and is controlled by iGPUThrottle. This setting can be found under ControlArray (Item 21 for iMac9,1) and is set to True. Making it a little too dangerous for my taste. At least for now without really knowing what it does. We need additional info/data.

 

Do you know what the "control-id" corresponds to? GPU class/family?

You can find the following items under ControlArray in ACPI_SMC_PlatformPlugin:

 

10 = CPU_PLIMIT

11 = GPU_PLIMIT

12 = MEM_PLIMIT

13 = CPU_STATE

14 = GPU_STATE

15 = IDLE_LIMIT

16 = GPU_RANGE_CONTROL_INTERNAL

17 = GPU_RANGE_CONTROL_EXTERNAL

18 = GPU_RANGE_CONTROL_PCI

 

Take a look at ValidConfigs under GPU_RANGE_CONTROL_PCI which is set to 18/0x12 (MacPro4,1). That is also why is doesn't really work for you with iMac9,1 set as model identifier.

 

And the following items under ControlLoopArray:

 

0 = SMC_CPU_Control_Loop

1 = SMC_GPU_sensor_Control_Loop

2 = SMC_Memory_Control_Loop

3 = SMC_GPU_Range_Control_Loop

 

Which is rather important. Let's have a look at CIA4 for the iMac9,1 which is set to: 3, 1 and 1. Now compare this with CIA7 for the MacPro4,1 There you'll find: 3, 18 and 0. Which happen to correspond with the following items:

 

SMC_GPU_Range_Control_Loop

GPU_RANGE_CONTROL_PCI

SMC_CPU_Control_Loop

 

Coincidence? I don't think so.

 

And the thresholds, are they degrees centigrade or a percentage of something?

Load percentage (0x64 is 100).

[FKA]

I continued my testing today, and this time I used MacPro4,1 data to find the following error in kernel.log:

 

ACPI_SMC_GPU_CtrlLoop::controlRegistered - unexpected control ID 16

 

The reason I got this error was because my model identifier is set to P5K PRO and thus there's nothing in AppleGraphicsPowerMangement.kext to match with. Enter a quick and dirty LegacyAGPM.kext (see attachments). Now my NVIDIA 9600GT (10de:0622) is recognized, and thus no more error. Oh and here's a handy link to lookup PCI vendor and device ID's.

 

Next things is to work on a LegacyACPI_SMC_PlatformPlugin.kext �" no more /S*/L*/Extensions hacks for me �" to enable NVIDIA throttling since that now only works with MacPro4,1 And I am not going to use this identifier but the one of a MacPro3,1 instead.

 

Can somebody please post ACPI dump from a MacPro4,1?

 

D.

[Master Chief]

<snip />

 

How to override SMC_Platform_Plugin.kext I described HERE

I thought to have killed another CPU:

 

But apparently it was just this code:

<dict>
<key>IOCPUNumber</key>
<integer>0</integer>
</dict>

 

Change it into 1 and then CPU2 is gone. All OK again after removing the kext.

 

p.s. Same problem with my still in progress LegacyACPI_SMC_PlatformPlugin.kext

[THe KiNG]

Dunno what you doing there...works perfect for me(and others)

 

Can somebody please post ACPI dump from a MacPro4,1?

 

D.

http://rapidshare.de/files/48290914/ACPI_M...mField.zip.html

[Master Chief]

Dunno what you doing there...works perfect for me(and others)

 

http://rapidshare.de/files/48290914/ACPI_M...mField.zip.html

What I did is this:

1) Copy kext into: /Extra/Extensions.

2) Reboot.

3) Start CPU-i.

 

And I am pretty sure that others here can reproduce this behaviour.

[FKA]

Dunno what you doing there...works perfect for me(and others)

 

 

http://rapidshare.de/files/48290914/ACPI_M...mField.zip.html

 

many thanks.

D

[FKA]

Dunno what you doing there...works perfect for me(and others)

 

 

http://rapidshare.de/files/48290914/ACPI_M...mField.zip.html

 

Should I need to remove/disable AppleTYMCEDriver.kext when setting MacPro4,1 as I don't have i7 CPU?

[harshw]

Should I need to remove/disable AppleTYMCEDriver.kext when setting MacPro4,1 as I don't have i7 CPU?

 

Yup - it works only with Nehalem

[spanakorizo]

what's the benefits of using mac pro 4.1 as a model instead of 3.1 ?

[FKA]

what's the benefits of using mac pro 4.1 as a model instead of 3.1 ?

 

I want to try The KiNgs legacy ACPI_SMC kext and GPU throttling works with MacPro4,1 identifyer.

 

D.