DSDT - Vanilla Speedstep - Generic Scope (_PR)

[blackosx]

However with speedstep, my CPU is running at 51 deg C which is on the high side and no auto sleep.

I have played around with only CPU0 & CPU1 only and that is why I asked you the question.

Following blackosx DSDT installation, I have 3C states even though my BIOS has only CPU EIST & C1E available only.

Changing to only 1C state in fact made it worst ( CPU temp rises to 54 deg C )

Not sure whether there is anything more I can do to bring down the CPU temp.

Hi helob

 

For your general running temps, double check you have removed NullCPUPowerManagement.kext from /E/E/.

Can you post your DSDT so we can have a look at it?

[helob]

Hi helob

 

For your general running temps, double check you have removed NullCPUPowerManagement.kext from /E/E/.

Can you post your DSDT so we can have a look at it?

Hello blackosx,

Confirmed that NullCPUPowerManagement.kext is NOT in E/E.

I have the following Kexts in Extension folder

Fakesmc.kext

LegacyHDA.kext

OpenHaltRestart.kext

PlatformUUID.kext

VoodooMonitor.kext

Here is my DSDT & VoodooMonitor results.

dsdt_w_Sata_UHC_HDEF_LPCB_speedstep.zip

Temp_VoodooMonitor.zip

PState_VoodooMonitor.zip

Appreciate any inputs on my DSDT {using Mobo GA-P35-DS3 (with ICH9 chipset) and Intel E8400 CPU}

 

 

TQ & Have a nice day.

[Aargh-a-Knot]

Well, I did a SSDT dump to get those address values, and created my Scope (_PR) to look like this:

 

	Scope (_PR)  
{
	Name (PPC, 0x00)
	Name (PCT, Package (0x02)
	{
		  ResourceTemplate ()
				{
					Register (SystemIO, 
						0x10,			   // Bit Width
						0x00,			   // Bit Offset
						0x0000000000000880, // Address
						,)
				}, 

		  ResourceTemplate ()
				{
					Register (SystemIO, 
						0x10,			   // Bit Width
						0x00,			   // Bit Offset
						0x0000000000000882, // Address
						,)
				}
	})
	Name (PSS, Package (0x04)
	{
			Package (0x06) { 0, 0, 10, 10, 0x091A, 0 }, 
			Package (0x06) { 0, 0, 10, 10, 0x0817, 1 },
			Package (0x06) { 0, 0, 10, 10, 0x0714, 2 },
			Package (0x06) { 0, 0, 10, 10, 0x0611, 3 }
	}) 	
	Name (PSD, Package (0x05)
	{
			0x05,0x00,0x00,0xFC,0x04  
	})	   
	Name (CST, Package (0x02)
	{
			0x01,
			Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x000, 0x01,)},1,0x01,0x0384}  
	})
	Processor (CPU0, 0X0, 0x00000410, 0X06)
	{
			Alias (PPC, _PPC)
			Alias (PCT, _PCT)
			Alias (PSS, _PSS)
			Alias (PSD, _PSD)
			Alias (CST, _CST) 
	}
	Processor (CPU1, 0X01, 0x00000410, 0X06)
	{
			Alias (PPC, _PPC)
			Alias (PCT, _PCT)
			Alias (PSS, _PSS)
			Alias (PSD, _PSD)
			Alias (CST, _CST) 
	}
	Processor (CPU2, 0X02, 0x00000410, 0X06)
	{
			Alias (PPC, _PPC)
			Alias (PCT, _PCT)
			Alias (PSS, _PSS)
			Alias (PSD, _PSD)
			Alias (CST, _CST) 
	}
	Processor (CPU3, 0X03, 0x00000410, 0X06)
	{
			Alias (PPC, _PPC)
			Alias (PCT, _PCT)
			Alias (PSS, _PSS)
			Alias (PSD, _PSD)
			Alias (CST, _CST) 
	}
} // end Scope(_PR)

 

However, I see no change... Voltage is still static. I'm using the values from my original SSDT, so I guess if they were going to work, they'd probably already be working from being loaded by the SSDT.

 

Any advice on what I could do different?

[blackosx]

Confirmed that NullCPUPowerManagement.kext is NOT in E/E.

.....

Here is my DSDT & VoodooMonitor results.

...

Appreciate any inputs on my DSDT {using Mobo GA-P35-DS3 (with ICH9 chipset) and Intel E8400 CPU}

Thanks for sending the info. I see you haven't included the Method _PSD in your Scope (_PR)? Have you applied the LPC fix as FormerlyKnownAs has described on the front page?

[FKA]

Thanks for sending the info. I see you haven't included the Method _PSD in your Scope (_PR)? Have you applied the LPC fix as FormerlyKnownAs has described on the front page?

 

Hi helob

 

Check ioreg for AppleLPC - if it's already loaded you may not need the LPC fix.

I have included in my DSDT but AppleLPC natively loads for my GA EP35 DS4 - ICH9-R board.

 

D.

[mitch_de]

Well, I did a SSDT dump to get those address values, and created my Scope (_PR) to look like this:

 

	Scope (_PR)  
{
	Name (PPC, 0x00)
	Name (PCT, Package (0x02)
	[size="1"] {
		  ResourceTemplate ()
				{
					Register (SystemIO, 
						0x10,			   // Bit Width
						0x00,			   // Bit Offset
						0x0000000000000880, // Address
						,)
				}, 

		  ResourceTemplate ()
				{
					Register (SystemIO, 
						0x10,			   // Bit Width
						0x00,			   // Bit Offset
						0x0000000000000882, // Address
						,)
				}
	}) [/size]
.

 

However, I see no change... Voltage is still static. I'm using the values from my original SSDT, so I guess if they were going to work, they'd probably already be working from being loaded by the SSDT.

 

Any advice on what I could do different?

 

Are you sure about that 880 / 882 Adresses (because all other are 4xx based) ?

I didnt have that PCT packadge content at all in my dsdt for GA-EP35 !

[Aargh-a-Knot]

Are you sure about that 880 / 882 Adresses (because all other are 4xx based) ?

I didnt have that PCT packadge content at all in my dsdt for GA-EP35 !

 

I'm sure that those are the addresses that are given in my SSDT. I've seen the same values in other EP45 Gigabyte boards also.

 

My DSDT did not have _PCT or _PPC in it... I'm playing around trying to get voltage stepping along with the P-States. I know this is possible, but maybe not with my hardware?? Or I am just not implementing the code properly....

 

I was just hoping someone might tell me where my logic is faltering on this, so I'm throwing it out there.

 

Something obviously needs to be different, or why wouldn't it work in the first place from my SSDT?

[blackosx]

My DSDT did not have _PCT or _PPC in it... I'm playing around trying to get voltage stepping along with the P-States. I know this is possible, but maybe not with my hardware?? Or I am just not implementing the code properly....

Hi Aargh-a-Knot

 

You might have already read it, but there was a lot of investigation and discussion about _PSS, _PCT & _PPC at the start of this thread and thoughout the first 10 or so pages. For instance here. Don't know if that's any use to your needs?

[Master Chief]

Well, I did a SSDT dump to get those address values, and created my Scope (_PR) to look like this:

see post 1078#

However, I see no change... Voltage is still static....

That's because what you see is the native Intel SpeedStep Technology at work. Not the Apple driver (kext). Check /var/log/kernel.log for _CST related errors. You may have one or two (I think).

[helob]

Thanks for sending the info. I see you haven't included the Method _PSD in your Scope (_PR)? Have you applied the LPC fix as FormerlyKnownAs has described on the front page?

 

blackosx,

Thanks for the usual prompt reply and guidance.

I have _PSD in my earlier DSDT but checking your DSDT (DSDT_GA_EP45_DS3L_091109),_PSD was omitted so I followed suit.

I did not find any change with or without _PSD as far as Temp is concerned.

What exactly does _PSD do?

I did applied the LPC fix and can be confirmed in the CSTinfo in IORegistryExplorer output (refer to attachment)

P_CState_status.zip

I see in some DSDT, it iclude SSDT info like so

 

"Scope (\)

{

Name (SSDT, Package (0x18)

{

"CPU0IST ",

0xCFEEE7D0,

0x0000022A,

"CPU1IST ",

0xCFEEEC90,

0x00000152,

"CPU0CST ",

0xCFEEF0B0,

0x0000018A,

"CPU1CST ",

0xCFEEF240,

0x0000018A,

"CPU2IST ",

0xCFEEEDF0,

0x00000152,

"CPU3IST ",

0xCFEEEF50,

0x00000152,

"CPU2CST ",

0xCFEEF3D0,

0x0000018A,

"CPU3CST ",

0xCFEEF560,

0x0000018A

})

Name (CFGD, 0x040383F2)

Name (\PDC0, 0x80000000)

Name (\PDC1, 0x80000000)

Name (\PDC2, 0x80000000)

Name (\PDC3, 0x80000000)"

 

Is this necessary and if so, what info does it provides to DSDT?

 

Tks & Have a nice day

 

 

 

 

Hi helob

 

Check ioreg for AppleLPC - if it's already loaded you may not need the LPC fix.

I have included in my DSDT but AppleLPC natively loads for my GA EP35 DS4 - ICH9-R board.

 

D.

 

Hi "FormerlyKnownAs"

TQ for your advise.

AppleLPC does not load natively on my Mobo (ICH9 chapset). Need to apply your fix to get it loaded.

Since I have only C1E in my BIOS, is it necessary to have all the 3C states in _CST?

TQ & Have a nice day.

[mitch_de]

I'm sure that those (8xx) are the addresses that are given in my SSDT. I've seen the same values in other EP45 Gigabyte boards also.

 

OK, so that two first 88x Adresses are OK.

But then check if all other (later in dsdt) Adresses are also 81x and not 41x based. (like 814 vs 414 and 815 vs 415!).

[blackosx]

I have _PSD in my earlier DSDT but checking your DSDT (DSDT_GA_EP45_DS3L_091109),_PSD was omitted so I followed suit.

If you also have the GA-EP45-DS3L (or, as I have recently learned, the EP45-UD3L) then I have a new DSDT on my thread which you should be able to use. It is based on mm67's work that he shared in the Gigabyte DSDT Fix thread.

 

I did not find any change with or without _PSD as far as Temp is concerned.

What exactly does _PSD do?

I think the _PSD section of code is supposed to help with the 'sensitivity' of the stepping, but I don't know for sure. I wouldn't have thought you'd notice a temperature drop with it, but I thought I would just mention it in my previous post.

 

I did applied the LPC fix and can be confirmed in the CSTinfo in IORegistryExplorer output (refer to attachment)

P_CState_status.zip

I see in some DSDT, it iclude SSDT info like so

I was thinking that might have been the cause for your higher CPU temps, but you have shown you have that loading so it can't be that then...

 

I see in some DSDT, it iclude SSDT info like so

 

"Scope (\)

{

Name (SSDT, Package (0x18)

{

"CPU0IST ",

......../SNIP/....

 

Is this necessary and if so, what info does it provides to DSDT?

This is what I think, but can somebody please correct me if I am wrong here....

 

If you have a look at the posts at the beginning of this thread, you will see that code being used. It comes from the SSDT tables which are part of your complete ACPI tables. These contain the C-state information, which you could add to your DSDT. Then because the system wouldn't load the data from the DSDT, the DropSSDT=Y boot option in your com.apple.Boot.plist was required to force the system to use it from your DSDT. But I think that method has been superceded by the way you can see in the latest DSDT's, under the _CST section.

[Aargh-a-Knot]

OK, so that two first 88x Adresses are OK.

But then check if all other (later in dsdt) Adresses are also 81x and not 41x based. (like 814 vs 414 and 815 vs 415!).

 

I was on the wrong track with that anyway. Those are indeed the address values, but for SystemIO, which is what is causing the Voltage not to step in the first place. Reading more about it, it appears that the way to get the voltage to step is to actually remove SystemIO and leave only FFixedHW, and also remove SPSS, using only NPSS, in the SSDT.

 

Now with this next question, you will see that I am talking way over my own head, but I think that If I can figure this last part out, I can really make it work.

 

So, I need to edit the SSDT for this to work. But, we can not inject a substitue SSDT here the way that we do with the DSDT, so what we need to do is include the SSDT information within the DSDT. I have seen that you can just add the info at the end of the DSDT, but here is what I'm not sure about: After doing a dump from an Ubuntu Live cd, I got 5 SSDT files; Cpu0lst, Cpu1lst, Cpu2lst, Cpu3lst (which are identical) and CpuM. The first four are what I want to over-ride. But, how to incorporate this info into my DSDT? I'm assuming that I need the info from CpuM still, but if I use DropSSDT=y, it will prevent this from loading? So it all needs to be added to the DSDT?

 

So I guess my question is, how to properly incorporate the SSDT into my DSDT and over-ride the SSDT from my BIOS?

 

 

@Master Chief

 

No, I see no _CST related errors, but I do have FakeSMC errors and a sound assertion error that I need to look after. Thanks for helping me notice those.

[mm67]

I was on the wrong track with that anyway. Those are indeed the address values, but for SystemIO, which is what is causing the Voltage not to step in the first place. Reading more about it, it appears that the way to get the voltage to step is to actually remove SystemIO and leave only FFixedHW, and also remove SPSS, using only NPSS, in the SSDT.

 

Now with this next question, you will see that I am talking way over my own head, but I think that If I can figure this last part out, I can really make it work.

 

So, I need to edit the SSDT for this to work. But, we can not inject a substitue SSDT here the way that we do with the DSDT, so what we need to do is include the SSDT information within the DSDT. I have seen that you can just add the info at the end of the DSDT, but here is what I'm not sure about: After doing a dump from an Ubuntu Live cd, I got 5 SSDT files; Cpu0lst, Cpu1lst, Cpu2lst, Cpu3lst (which are identical) and CpuM. The first four are what I want to over-ride. But, how to incorporate this info into my DSDT? I'm assuming that I need the info from CpuM still, but if I use DropSSDT=y, it will prevent this from loading? So it all needs to be added to the DSDT?

 

So I guess my question is, how to properly incorporate the SSDT into my DSDT and over-ride the SSDT from my BIOS?

 

 

@Master Chief

 

No, I see no _CST related errors, but I do have FakeSMC errors and a sound assertion error that I need to look after. Thanks for helping me notice those.

 

You might want to take a look at Acpispec40 page 135. There you will find this sentence:

 

Note: Additional tables can only add data; they cannot overwrite data from previous tables

 

So when we are defining PSS and CST tables in DSDT without using DropSSDT=y option we are just overriding those tables from SSDT, everything else from SSDT is still loaded normally.

 

Are you really sure that your voltages are not changing, I don't think that anyone else has such a problem. You might want to check that you don't have some kext disabling vanilla powermanagement, NullCpuPowerManagement.kext at least does exactly that. Multipliers change but voltage is always at highest level.

[kdawg]

You might want to take a look at Acpispec40 page 135. There you will find this sentence:

 

Note: Additional tables can only add data; they cannot overwrite data from previous tables

 

So when we are defining PSS and CST tables in DSDT without using DropSSDT=y option we are just overriding those tables from SSDT, everything else from SSDT is still loaded normally.

 

Are you really sure that your voltages are not changing, I don't think that anyone else has such a problem. You might want to check that you don't have some kext disabling vanilla powermanagement, NullCpuPowerManagement.kext at least does exactly that. Multipliers change but voltage is always at highest level.

So mm67 are you using DropSSDT=y? For me, either way it seems to have no impact on the performance of my machine so I've just omitted it.

[mm67]

So mm67 are you using DropSSDT=y? For me, either way it seems to have no impact on the performance of my machine so I've just omitted it.

 

No, I am not using that option. Like you I also can't see any difference if I use it or not but at least I know that everything is loaded like it should be.

[kdawg]

No, I am not using that option. But like you I also can't see any difference if I use it or not.

Right, just checking.

[Aargh-a-Knot]

You might want to take a look at Acpispec40 page 135. There you will find this sentence:

 

Note: Additional tables can only add data; they cannot overwrite data from previous tables

 

So when we are defining PSS and CST tables in DSDT without using DropSSDT=y option we are just overriding those tables from SSDT, everything else from SSDT is still loaded normally.

 

Right. This is why I am trying to figure out how to add the entirety of the SSDT data into my DSDT, and then use DropSSDT=Y.

 

Are you really sure that your voltages are not changing, I don't think that anyone else has such a problem. You might want to check that you don't have some kext disabling vanilla powermanagement, NullCpuPowerManagement.kext at least does exactly that. Multipliers change but voltage is always at highest level.

 

Am I sure? Well, I am only going on what VoodooMonitor is telling me. Under Status, I can see the frequency, multiplier and temperature changing, but voltage remains static. Interestingly, the voltage remains at 1.132v, which is not what any of my P-States are set at.

 

I am absolutely sure that I am not using NullCpuPowerManagement.kext.

 

By "Multipliers change but voltage is always at highest level", you mean when using NCPM, correct?

 

What does everyone else see? Are you guys seeing your voltage change along with the multiplier in VoodooMonitor? If not, then how do you know it is changing?

 

Also, the whole basis of this "quest", is AsereBLN's post, HERE. In it he describes how he was able to get the voltage to step with the P-States by "removing the SytemIO stuff" Also, in the bold section of the following blurb, he indicates that he can see the result of this change in CPU-I:

 

_PCT stands for Performance Control (ACPI spec chapter 8.4.4.1)and declares an interface that allows OSPM to transition to a specific performance state. I know to methods: one uses directly the CPU Performance Control Register (FFixedHW, 0x199) and the other one uses SystemIO to configure the P-State. I tried both methods on my system. Both are able to change the frequency, but only the direct method using the PERF_CTRL register could also change the voltage (checked with CPU-I).

 

I'm assuming this would also be seen in VoodooMonitor (Are they in fact the same app?)

 

He also says that the same can be achieved by changing CFGD... I don't know what would be the most straight forward way to accomplish this. Maybe just overwriting the CFGD value? You can see that AsereBLN left this as a cliffhanger, nearly a month ago, without detailing exactly HOW to make these changes. I just got a little impatient, and decided to try and figure this out on my own, but I am missing a bit of data on how exactly to implement the concept. I would ask AsereBLN, but he seems to be too busy at the moment for this stuff.

[mm67]

Right. This is why I am trying to figure out how to add the entirety of the SSDT data into my DSDT, and then use DropSSDT=Y.

 

 

 

Am I sure? Well, I am only going on what VoodooMonitor is telling me. Under Status, I can see the frequency, multiplier and temperature changing, but voltage remains static. Interestingly, the voltage remains at 1.132v, which is not what any of my P-States are set at.

 

I am absolutely sure that I am not using NullCpuPowerManagement.kext.

 

By "Multipliers change but voltage is always at highest level", you mean when using NCPM, correct?

 

What does everyone else see? Are you guys seeing your voltage change along with the multiplier in VoodooMonitor? If not, then how do you know it is changing?

 

Also, the whole basis of this "quest", is AsereBLN's post, HERE. In it he describes how he was able to get the voltage to step with the P-States by "removing the SytemIO stuff" Also, in the bold section of the following blurb, he indicates that he can see the result of this change in CPU-I:

 

 

 

I'm assuming this would also be seen in VoodooMonitor (Are they in fact the same app?)

 

We are loading the entire SSDT by not using DropSSDT=y option, we are only overriding PSS and CST tables by defining them already in DSDT before SSDT tables are loaded.

 

And yes, I do see voltages changing when using VoodooMonitor.

 

And I meant that voltage value is static when using NullCpu...kext

[FKA]

@Master Chief

 

No, I see no _CST related errors, but I do have FakeSMC errors and a sound assertion error that I need to look after. Thanks for helping me notice those.

 

Hi Aargh-a-knot

 

Question are you using MacPro4,1 model id?

EDIT ## And if so, as you're not i7 you've removed AppleTYMCEDriver.kext!?

 

D.

[Aargh-a-Knot]

Hi Aargh-a-knot

 

Question are you using MacPro4,1 model id?

EDIT ## And if so, as you're not i7 you've removed AppleTYMCEDriver.kext!?

 

D.

 

No, I'm using MacPro3,1.

[FKA]

No, I'm using MacPro3,1.

 

that's that theory buggered ...

 

I have the same symptoms (multi's switching voltage not!) when I use MP4,1 model id.

Wondering if its related - I'd like to use MP4,1 to get AGPM loaded .. i was assuming not having AppleTYMCEDriver.kext may have something to do with it!

 

D.

[Master Chief]

So mm67 are you using DropSSDT=y? For me, either way it seems to have no impact on the performance of my machine so I've just omitted it.

I want to know things for sure... so can we please verify this?

 

Now. The source code for this boot option can be found in: i386/libsaio/dsdt_patcher.c

 

And looking at it; what it does is to check the RSDT table for SSDT tables, by comparing the first four characters, and then to skip them, and lastly fix the checksum. That's the easy / ultra simple explanation of it.

drop_ssdt=getBoolForKey("DropSSDT",&tmp, &bootInfo->bootConfig)&&tmp;
...
if (drop_ssdt && table[0]=='S' && table[1]=='S' && table[2]=='D' && table[3]=='T')
{
dropoffset++;
continue;
}
...
rsdt_mod->Checksum=0;
rsdt_mod->Checksum=256-checksum8(rsdt_mod,rsdt_mod->Length);

Which basically means that you can verify this. Just take a look at the RSDT table, because it should be shorter / different with the DropSSDT=yes option. I would recommend IORegistryExplorer for this – the ACPI tables can be found under: AppleACPIPlatformExpert -> ACPI Tables.

 

Note: I can't remember having seen a single hack with any SSDT tables in IORegistryExplorer, but on my MacPro. I remember MatthewL's case where CpuPm.dsl was responsible for loading other tables. I even wrote a little _INI Method for him in post #477 (see follow ups).

 

But, not having any SSDT tables there doesn't necessarily mean that there aren't any since you can load tables with help of Load (). We however removed all code snippets with Load statements, simply because we don't need them. And thus some of us won't need this boot option

 

And yes, the DSDT table there is your dsdt.aml

 

p.s. If you do happen to have a file called CpuPm.dsl and it loads other tables, then you should use this DropSSDT. Period.

[blackosx]

Note: I can't remember having seen a single hack with any SSDT tables in IORegistryExplorer, but on my MacPro.

Mine has SSDT tables in IORegistryExplorer.

 

p.s. If you do happen to have a file called CpuPm.dsl and it loads other tables, then you should use this DropSSDT. Period.

I have just added the DropSSDT option to my com.apple.Boot.plist and rebooted. And yes, as you showed, they are now gone from IORegistryExplorer.

[Master Chief]

Mine has SSDT tables in IORegistryExplorer.

..I have just added the DropSSDT option to my com.apple.Boot.plist and rebooted. And yes, as you showed, they are now gone from IORegistryExplorer.

Thank you for the confirmation!

 

And thus as a golden rule... from now on: When you see (a) SSDT-n table(s) in there, then you should use DropSSDT=yes when you changed / fixed your DSDT. Otherwise it has no meaning.

 

I wonder if this saves you revs at startup. Does it?

 

that's that theory buggered ...

 

I have the same symptoms (multi's switching voltage not!) when I use MP4,1 model id.

Wondering if its related - I'd like to use MP4,1 to get AGPM loaded .. i was assuming not having AppleTYMCEDriver.kext may have something to do with it!

 

D.

That's IMHO because you don't have a Nehalem which use new / different techniques to reduce power usage. You need a Legacy kext to get it working, but the question remains if it does anything useful.