1945 replies to this topic

[Master Chief]

FormerlyKnownAs, on Sep 5 2009, 11:11 PM, said:

Dude have you read and understood any of the thread?

Let's be fair shall we?  Let's read page 292 of the specification, which clearly states:

Each performance state entry contains six data fields as follows:
CoreFreq. Indicates the core CPU operating frequency (in MHz).
Power. Indicates the performance state��‚��„�s maximum power dissipation (in milliWatts).
TransitionLatency. Indicates the worst-case latency in microseconds that the CPU is unavailable
during a transition from any performance state to this performance state.
BusMasterLatency. Indicates the worst-case latency in microseconds that Bus Masters are prevented
from accessing memory during a transition from any performance state to this performance state.
Control. Indicates the value to be written to the Performance Control Register (PERF_CTRL) in order
to initiate a transition to the performance state.
Status. Indicates the value that OSPM will compare to a value read from the Performance Status
Register (PERF_STATUS) to ensure that the transition to the performance state was successful. OSPM may always place the CPU in the lowest power state, but additional states are only available when indicated by the _PPC method.

And thus there is no multiplier anywhere in the _PSS.  Let's tackle your next blurb:

FormerlyKnownAs, on Sep 5 2009, 11:11 PM, said:

The important values being fid (mutiplier value i.e 7.5) and vid
UCpu = 800 mV + vid*12.5 mV
ergo vid = [vCore -800mV]/12.5mV

You just got that from some "guide" on the Internet, but point me to a single document, a single page in the specification where it states that you need to calculate PERF_CTRL and PERF_STATUS like that!  No to mention this next snippet:

Name (_PSS, Package() {
Package(){650, 21500, 500, 300, 0x00, 0x08}, // Performance State zero (P0) 
Package(){600, 14900, 500, 300, 0x01, 0x05}, // Performance State one (P1)
Package(){500, 8200, 500, 300, 0x02, 0x06} // Performance State two (P2)
}) // End of _PSS object

Take a look at the Performance States!  Note the 8, 5 and 6 here.  Why is it that the P-States Calculator gives me other values?  How do I know which one is right, if I can't check it myself?  

p.s. Try not to attack people who are only trying to help you!

[FKA]

Master Chief, on Sep 5 2009, 10:40 PM, said:

Let's be fair shall we?  Let's read page 292 of the specification, which clearly states:

Each performance state entry contains six data fields as follows:
CoreFreq. Indicates the core CPU operating frequency (in MHz).
Power. Indicates the performance state��‚��„�s maximum power dissipation (in milliWatts).
TransitionLatency. Indicates the worst-case latency in microseconds that the CPU is unavailable
during a transition from any performance state to this performance state.
BusMasterLatency. Indicates the worst-case latency in microseconds that Bus Masters are prevented
from accessing memory during a transition from any performance state to this performance state.
Control. Indicates the value to be written to the Performance Control Register (PERF_CTRL) in order
to initiate a transition to the performance state.
Status. Indicates the value that OSPM will compare to a value read from the Performance Status
Register (PERF_STATUS) to ensure that the transition to the performance state was successful. OSPM may always place the CPU in the lowest power state, but additional states are only available when indicated by the _PPC method.

And thus there is no multiplier anywhere in the _PSS.  Let's tackle your next blurb:


You just got that from some "guide" on the Internet, but point me to a single document, a single page in the specification where it states that you need to calculate PERF_CTRL and PERF_STATUS like that!  No to mention this next snippet:

Name (_PSS, Package() {
  Package(){650, 21500, 500, 300, 0x00, 0x08}, // Performance State zero (P0) 
  Package(){600, 14900, 500, 300, 0x01, 0x05}, // Performance State one (P1)
  Package(){500, 8200, 500, 300, 0x02, 0x06} // Performance State two (P2)
  }) // End of _PSS object

Take a look at the Performance States!  Note the 0, 1 and 2 here.  How com the P-States Calculator get other values?  

p.s. Try not to attack people who are only trying to help you!

I don't see how your trying to help me? You just making me regurgitate whats already been posted.

PERF_CTRL - is the multi and vid value you are trying to achive
PERF_STATUS - is the value you are looking for after a sucessful transition

this value is in HEX ~> (muti)(vid)

from ztex.de  -
The frequency ID (fid) is the multiplier for the reference clock (e.g. the FSB clock). The voltage ID (vid) is processor specific. Unfortunately Intel publishes no information about the meaning of this value but the conversion formula for Core CPU's seems to be   UCpu = 700 mV + vid*12.5 mV
and for Core 2 CPU's it seems to be   UCpu = 800 mV + vid*12.5 mV .

So no you wont find this anywhere in document because intel havent published it!!

Yes your PSS can be writen as (posted by roisoft.)

Name (_PSS, Package ()
{
Package (0x06) { 2403, 64260, 32, 32, 0x928, 0x000 },
Package (0x06) { 2136, 55669, 32, 32, 0x826, 0x001 },
Package (0x06) { 1869, 46806, 32, 32, 0x722, 0x002 },
Package (0x06) { 1602, 38488, 32, 32, 0x61E, 0x003 }
})
}

You will see the 5th set of data for each state 0x928, 0x826, 0x722
0x928 > multi = 9 , vid = 28 (in hex)

Your PSS table only seems to have a multiplier value and they are in the wrong order 8- P0, 5- P1 and 6- P2

The only data in that table we can't easily calculate is power (the second set of data.) this is what you can find using p-state calulator - but as previously stated this value doesn't seem to matter (although I could be wrong!) as it doesn't get reported back to BIOS in OSX and change anything - neither does the frequency value but it's got to be safest to get it right - I agree.

If you want your p-states to work you need to enter / EDIT this information in the PSS table .

Thank you So much for you fantastic help here!


D.

P.S. get a dictionary and look up curmudgeon!

[Master Chief]

FormerlyKnownAs, on Sep 6 2009, 12:16 AM, said:

I don't see how your trying to help me? You just making me regurgitate whats already been posted....

Well well.  You keep being impolite and jumping over stuff like a little rabbit.  Now, let's start by acknowledging (yes you) that:

1) The P-States Calculator has issues with fractions.
2) CPU-I crashes in Snow Leopard and has to be rebuilt.
3) There is NO multiplier info in _PSS.
4) There is no proof whatsoever that "your" calculation for PERF_CTRL and PERF_STATUS is correct. In fact it simply contradicts with the information found in the ACPI specification (see my previous example from page 295).

Also, take a look at this post:
"There is inconsistence of vcore reported by different tools.
cpuz (win tools) seems use equation of vcore = 712.5mv + 12.5mv *vid
P-States Calculator and MSR tool (from your post) seems use: vcore = 700mv +16mv*vid
cpu-x does not report vcore."

As in I wasn't the first person to question this, but don't take it so personally – you really do you know – because that is not my mission here.

Edit: You obviously have issues with people like me who want to see stuff in black and white, call it proof, but you keep defending information that isn't even yours to start with.  Do you know these people personally?   If that's a yes... then you speak German and thus I say: Auf Wiedersehen.

[FKA]

Master Chief, on Sep 5 2009, 11:43 PM, said:

Well well.  You keep being impolite and jumping over stuff like a little rabbit.  Now, let's start by acknowledging (yes you) that:

1) The P-States Calculator has issues with fractions.
2) CPU-I crashes in Snow Leopard and has to be rebuilt.
3) There is NO multiplier info in _PSS.
4) There is no proof whatsoever that "your" calculation for PERF_CTRL and PERF_STATUS is correct. In fact it simply contradicts with the information found in the ACPI specification (see my previous example from page 295).

Also, take a look at this post:
"There is inconsistence of vcore reported by different tools.
cpuz (win tools) seems use equation of vcore = 712.5mv + 12.5mv *vid
P-States Calculator and MSR tool (from your post) seems use: vcore = 700mv +16mv*vid
cpu-x does not report vcore."

As in I wasn't the first person to question this, but don't take it so personally �" you really do you know �" because that is not my mission here.

Edit: You obviously have issues with people like me who want to see stuff in black and white, call it proof, but you keep defending information that isn't even yours to start with.  Do you know these people personally?   If that's a yes... then you speak German and thus I say: Auf Wiedersehen.

dude, your comments are welcome.

If you'd followed this method properly - they would be relevant!

you haven't - there not!

see you on the flipside

[jinnggoff]

Beerkex'd, on Sep 4 2009, 03:23 AM, said:

Modifying AppleLPC.kext gave me the mythical "Automatically restart after power failure" checkbox in energy saver, that you're supposed to tick to fix sleep (AKA "Jan Bird fix" - http://www.insanelym...p...t&p=1004881 ). I've been chasing that one for more than six months, so seeing that checkbox is like finding lost treasure.

However, as Murphy's Law dictates, S3 sleep broke after doing this no matter if the box is ticked or not!  

On the other hand, I can now shut down properly without OpenHaltRestart.kext.

It will be interesting to see if sleep works again if I undo the modification to AppleLPC.kext.

/EDIT, yes, S3 sleep came back

Searching for AppleLPC.kext comes up with lots of good stuff, I never knew about this. Interesting. Oh and sorry about the minor threadjack.

Yes indeed... I got sleep problem too, can sleep but cannot wake up ....
the strange is when applelpc.kext is loading with vanilla device id....there is nothing problem with sleep...
edit
Sleep is working fine..after check "Automatically restart after power failure"....Many thanks Beerkex'd..for your info

[Master Chief]

FormerlyKnownAs, on Sep 5 2009, 07:55 PM, said:

...Add this data to the SPSS and NPSS tables (only difference betwen NPSS and SPSS is the latancy value.)

Would you mind checking something for me?   Please add a latency value greater than 100 (indicates the system does not support a C2 state) and a latency greater than 1000 (indicates the system does not support a C3 state) to see if this information is correct?  

Thank you!

[FKA]

Master Chief, on Sep 6 2009, 04:44 PM, said:

Would you mind checking something for me?   Please add a latency value greater than 100 (indicates the system does not support a C2 state) and a latency greater than 1000 (indicates the system does not support a C3 state) to see if this information is correct?  

Thank you!

My Friend

I'm unfortunatly at work until late.

Where are you getting such high latency values from? - The values in your tables (post #34) are:

Name (XPSS, 0x02)
		Name (_PPC, 0x00)
		Name (SPSS, Package (0x02)
		{
			Package (0x06)
			{
				0x000009C1, 
				0x000157C0, 
				0x0000006E, \\latency 
				0x0000000A, \\ latency
				0x00000086, 
				0x00000000
			}, 

			Package (0x06)
			{
				0x000007CE, 
				0x0000A3A0, 
				0x0000006E, \\ latency
				0x0000000A, \\ latency
				0x00000186, 
				0x00000001
			}
		})
		Name (NPSS, Package (0x02)
		{
			Package (0x06)
			{
				0x000009C1, 
				0x000157C0, 
				0x0000000A, \\latency
				0x0000000A, \\ latency
				0x00004720, 
				0x00004720
			}, 

			Package (0x06)
			{
				0x000007CE, 
				0x0000A3A0, 
				0x0000000A, \\ latency
				0x0000000A, \\ latency
				0x0000061A, 

Why on earth are you entering values of 100 and 1000 ?? Am I missing something ??

Are you still refering back to the example given in the ACPI 3.0 specs?
Which let's be perfectly clear, is given as an example for an unknown processor where the performance states being defined are unknown quantities:

8.4.4.4 Processor Performance Control Example
EXAMPLE:
This is an example of processor performance control objects in a processor object list.
In this example, a uniprocessor platform that has processor performance capabilities with support for three
performance states as follows:
1. 500 MHz (8.2W) supported at any time
2. 600 MHz (14.9W) supported only when AC powered
3. 650 MHz (21.5W) supported only when docked
It takes no more than 500 microseconds to transition from one performance state to any other performance
state.
During a performance transition, bus masters are unable to access memory for a maximum of 300
microseconds.
The PERF_CTRL and PERF_STATUS registers are implemented as Functional Fixed Hardware.
The following ASL objects are implemented within the system:
\_SB.DOCK: Evaluates to 1 if system is docked, zero otherwise.
\_SB.AC: Evaluates to 1 if AC is connected, zero otherwise.
Processor (
\_SB.CPU0, // Processor Name
1, // ACPI Processor number
0x120, // PBlk system IO address
6 ) // PBlkLen
{
Name(_PCT, Package () // Performance Control object
{
ResourceTemplate(){Register(FFixedHW, 0, 0, 0)}, // PERF_CTRL
ResourceTemplate(){Register(FFixedHW, 0, 0, 0)} // PERF_STATUS
}) // End of _PCT object
Name (_PSS, Package()
{
Package(){650, 21500, 500, 300, 0x00, 0x08}, // Performance State zero (P0)
Package(){600, 14900, 500, 300, 0x01, 0x05}, // Performance State one (P1)
Package(){500, 8200, 500, 300, 0x02, 0x06} // Performance State two (P2)

D.

[hackcat]

I chose to go only for adding p-states to my dsdt without borrowing the MacPro3,1 c-states. That works for me. I shave off maybe 5 to 7°C, but not quite the lower consumption that having the c-states enabled. With the c-states borrowed per core temps dropped up to 15°C. But this way, no audio stutter, no patchy animations. So at least I narrowed down the source of my problems.

[FKA]

hackcat, on Sep 6 2009, 10:02 PM, said:

I chose to go only for adding p-states to my dsdt without borrowing the MacPro3,1 c-states. That works for me. I shave off maybe 5 to 7°C, but not quite the lower consumption that having the c-states enabled. With the c-states borrowed per core temps dropped up to 15°C. But this way, no audio stutter, no patchy animations. So at least I narrowed down the source of my problems.

Good work hackcat

c-states would be great - I'm sure we'll work it out eventually.

D.

[Brett Whinnen]

How many people are working on this issue with Snow Leopard?

I've got some 'borrowed' _CST tables (they look very similar to the 3,1 tables) and whilst I get the _PSS tables all loaded via the native IntelCPUPowerManagement I still get the LPC error relating to C-states. This was all working under 10.5.7 but has raised as an issue under 10.6.

I can attach any files of relevance that people would like to see here. It is annoying me to know end at the moment

Cheers,

Brett

[FKA]

Brett Whinnen, on Sep 6 2009, 10:39 PM, said:

How many people are working on this issue with Snow Leopard?

I've got some 'borrowed' _CST tables (they look very similar to the 3,1 tables) and whilst I get the _PSS tables all loaded via the native IntelCPUPowerManagement I still get the LPC error relating to C-states. This was all working under 10.5.7 but has raised as an issue under 10.6.

I can attach any files of relevance that people would like to see here. It is annoying me to know end at the moment

Cheers,

Brett

where have you acquired the cst tables from?
I have had to set in SMBIOS the model to MacPro3,1 - which is where i got the cst.

also an edit needed to acpi_smc_platformplugin.kext plist - see earlier post in this thread.

let us know how you go.

D.

[Brett Whinnen]

FormerlyKnownAs, on Sep 7 2009, 09:23 AM, said:

where have you acquired the cst tables from?
I have had to set in SMBIOS the model to MacPro3,1 - which is where i got the cst.

also an edit needed to acpi_smc_platformplugin.kext plist - see earlier post in this thread.

let us know how you go.

D.

I was using ones from a MBP5,1 which have a couple of extra defines in them. I've also tried the actual ones from my Laptop, but not set anything in ACPI_SMC_PlatformPlugin.kext

from dmesg | grep ACPI

AppleACPICPU: ProcessorId=1 LocalApicId=1 Enabled
ACPI: System State [S0 S3 S4 S5] (S3)
ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized
Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IDE0@1F,2/AppleICH8AHCI/PRI@0/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/WDC WD3200BEVT-75ZCT0 Media/IOGUIDPartitionScheme/Untitled@3

Excerpt from DSDT.dsl (_PSS values are from my T9300 cpu, taken from acpidump).

	Scope (_PR)
	{
		Processor (CPU0, 0x00, 0x00001010, 0x06)
		{
			Method (_CST, 0, NotSerialized)
			{
				If (LAnd (And (CFGD, 0x01000000), LNot (And (PDC0, 0x10
					))))
				{
					Return (Package (0x02)
					{
						One, 
						Package (0x04)
						{
							ResourceTemplate ()
							{
								Register (FFixedHW, 
									0x00,			   // Bit Width
									0x00,			   // Bit Offset
									0x0000000000000000, // Address
									,)
							}, 

							One, 
							0x9D, 
							0x03E8
						}
					})
				}

				If (And (PDC0, 0x0300))
				{
					If (And (CFGD, 0x20))
					{
						Return (Package (0x03)
						{
							0x02, 
							Package (0x04)
							{
								ResourceTemplate ()
								{
									Register (FFixedHW, 
										0x01,			   // Bit Width
										0x02,			   // Bit Offset
										0x0000000000000000, // Address
										,)
								}, 

								One, 
								One, 
								0x03E8
							}, 

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

								0x02, 
								One, 
								0x01F4
							}
						})
					}
				}

				If (And (CFGD, 0x20))
				{
					Return (Package (0x03)
					{
						0x02, 
						Package (0x04)
						{
							ResourceTemplate ()
							{
								Register (FFixedHW, 
									0x01,			   // Bit Width
									0x02,			   // Bit Offset
									0x0000000000000000, // Address
									,)
							}, 

							One, 
							One, 
							0x03E8
						}, 

						Package (0x04)
						{
							ResourceTemplate ()
							{
								Register (SystemIO, 
									0x08,			   // Bit Width
									0x00,			   // Bit Offset
									0x000000000000000C, // Address
									,)
							}, 

							0x02, 
							One, 
							0x01F4
						}
					})
				}

				Return (Package (0x02)
				{
					One, 
					Package (0x04)
					{
						ResourceTemplate ()
						{
							Register (FFixedHW, 
								0x01,			   // Bit Width
								0x02,			   // Bit Offset
								0x0000000000000000, // Address
								,)
						}, 

						One, 
						One, 
						0x03E8
					}
				})
			}
			Name (_PSS, Package (0x06)
			{
				Package (0x06)
				{
					0x09C5, 
					0x7D00, 
					0x0A, 
					0x0A, 
					0x4D28, 
					0x4D28
				}, 

				Package (0x06)
				{
					0x09C4, 
					0x7918, 
					0x0A, 
					0x0A, 
					0x4C22, 
					0x4C22
				}, 

				Package (0x06)
				{
					0x07D0, 
					0x5DC0, 
					0x0A, 
					0x0A, 
					0x0A1E, 
					0x0A1E
				}, 

				Package (0x06)
				{
					0x0640, 
					0x4650, 
					0x0A, 
					0x0A, 
					0x081B, 
					0x081B
				}, 

				Package (0x06)
				{
					0x04B0, 
					0x32C8, 
					0x0A, 
					0x0A, 
					0x0617, 
					0x0617
				}, 

				Package (0x06)
				{
					0x0320, 
					0x2710, 
					0x0A, 
					0x0A, 
					0x8813, 
					0x8813
				}
			})
		}

		Processor (CPU1, 0x01, 0x00001010, 0x06)
		{
			Method (_CST, 0, NotSerialized)
			{
				Return (^^CPU0._CST ())
			}

			Name (_PSS, Package (0x06)
			{
				Package (0x06)
				{
					0x09C5, 
					0x7D00, 
					0x0A, 
					0x0A, 
					0x4D28, 
					0x4D28
				}, 

Excerpt from /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Info.plist

								<key>CStateDemotionDict</key>
								<dict>
<!--									<key>MacPro4,1</key> -->
<!--									<key>MacBookPro5,1</key> -->
										<key>MacPro3,1</key>
										<string>CSDD_std1</string>
										<key>Xserve3,1</key>
										<string>CSDD_std1</string>
								</dict>

And finally from /Extra/smbios.plist

		<key>SMproductname</key>
		<string>MacPro3,1</string>

Have I done it correctly?

And this is under Snow Leopard as I mentioned previously.

Thanks again.

Brett

[FKA]

Brett Whinnen, on Sep 7 2009, 03:29 AM, said:

Have I done it correctly?

And this is under Snow Leopard as I mentioned previously.

Thanks again.

Brett

Hi Brett

Try this in the info plist (may work!)


<key>CStateDemotionDict</key>
                                <dict>
<key>MacBookPro5,1</key>
                                        <string>CSDD_std1</string>
                                        <key>Xserve3,1</key>
                                        <string>CSDD_std1</string>
                                </dict>


D

OK I have a question -

The following  _cst package example:

Name(_CST, Package()
{
4, // There are four C-states defined here with three semantics
// The third and fourth C-states defined have the same C3 entry semantics
Package(){ResourceTemplate(){Register(FFixedHW, [color="#ff0000"]0, 0, 0)}, 1, 20, 1000[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x161)}, 2, 40, 750[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x162)}, 3, 60, 500[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x163)}, 3, 100, 250[/color]}
})

Does anybody know what the data highlited in red corresponds to?
With a view to adding correct data for a given CPU.

D.

[Brett Whinnen]

FormerlyKnownAs, on Sep 7 2009, 12:50 PM, said:

Hi Brett

Try this in the info plist (may work!)


<key>CStateDemotionDict</key>
                                <dict>
<key>MacBookPro5,1</key>
                                        <string>CSDD_std1</string>
                                        <key>Xserve3,1</key>
                                        <string>CSDD_std1</string>
                                </dict>


D

That is what I am running now. And still get the

ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized

Error. Which leads me to believe they may not be from a MBP5,1 after all. With the logs above I was using just the MP3,1 items from the linked post on the first page and the smbios was setting it to be a MP3,1 which it was displayed as in System Profiler...

Quote

Using the same method I added _cst (c-states) SSDT tables from MacPro3,1 (as my MB does not have any!) These tables are posted by roisoft in post #70 here

Cheers,

Brett

[FKA]

Look carefully at what I've posted - It is not the same !

<key>CStateDemotionDict</key>
                                <dict>
<key>MacBookPro5,1</key>
                                        <string>CSDD_std1</string>
                                        <key>Xserve3,1</key>
                                        <string>CSDD_std1</string>
                                </dict>

***EDIT*** If the above does not work in info.plist and you are unsure if you are using the correct SSDT from MBP5,1 then you can find SSDT and DSDT tables for various Mac models in post7
here - curt' roisoft

D.

[Brett Whinnen]

FormerlyKnownAs, on Sep 7 2009, 01:01 PM, said:

Look carefully at what I've posted - It is not the same !

<key>CStateDemotionDict</key>
                                <dict>
<key>MacBookPro5,1</key>
                                        <string>CSDD_std1</string>
                                        <key>Xserve3,1</key>
                                        <string>CSDD_std1</string>
                                </dict>

***EDIT*** If the above does not work in info.plist and you are unsure if you are using the correct SSDT from MBP5,1 then you can find SSDT and DSDT tables for various Mac models in post7
here - curt' roisoft

D.

I should have posted what I was using after those logs above (or should I say prior to). Which is as far as I can see the same as you posted above. I did go to the point of copying that and pasting it in place of what I had in there anyway. The comments were to show what was original, what I then had and what I then placed to run the 3,1 test.

But I still get the following:

AppleACPICPU: ProcessorId=0 LocalApicId=0 Enabled
AppleACPICPU: ProcessorId=1 LocalApicId=1 Enabled
ACPI: System State [S0 S3 S4 S5] (S3)
ACPI_SMC_PlatformPlugin::registerLPCDriver - WARNING - LPC device initialization failed: C-state power management not initialized
Got boot device = IOService:/AppleACPIPlatformExpert/PCI0@0/AppleACPIPCI/IDE0@1F,2/AppleICH8AHCI/PRI@0/IOAHCIDevice@0/AppleAHCIDiskDriver/IOAHCIBlockStorageDevice/IOBlockStorageDriver/WDC WD3200BEVT-75ZCT0 Media/IOGUIDPartitionScheme/Untitled@3

About to go in search of some other CST tables from the link you posted. Might try a different model from the MBP5,1 I am using now... MBP4,1 would be closest to my actual hardware but we'll see where we end. Will report back, I really want to get this error removed, call it being pedantic if you will.

This is great work and I think this is the best approach we can have.

Thanks,

Brett

[sk1nhead]

looking at the guide it's not as easy as copy paste to my DSDT unlike other guides out there..

question, anyone care to explain the advantage of this compared to voodoopower? ive seen only few members posting so im assuming not that much or really no one cared about speedstep and just happy they have OSX running.

[Master Chief]

FormerlyKnownAs, on Sep 7 2009, 04:58 AM, said:

OK I have a question -
The following  _cst package example:

Name(_CST, Package()
{
4, // There are four C-states defined here with three semantics
// The third and fourth C-states defined have the same C3 entry semantics
Package(){ResourceTemplate(){Register(FFixedHW, [color="#ff0000"]0, 0, 0)}, 1, 20, 1000[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x161)}, 2, 40, 750[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x162)}, 3, 60, 500[/color]},
Package(){ResourceTemplate(){Register(SystemIO, [color="#ff0000"]8, 0, 0x163)}, 3, 100, 250[/color]}
})

Does anybody know what the data highlited in red corresponds to?
With a view to adding correct data for a given CPU.

Let's take the last one as example:
8 = 8 bits.
0 = index address 0.
0x163 = Register (must be unique per _CST object).

Register(SystemIO, 8, 0, 0x163) // OSPM reads 8 bits, starting at index 0, from register 0x163 to go into this state.

3 = C-State aka C3.
100 = Latency in microseconds (worse  case) to change C-State.
250 = Average power consumption in milliwatt (per core).

Now assume that core 0 is in C3 (using 1000mw) but has a little less work to do, reducing the average power usage to say 750mw (in this case) for over 40us, that will make it changes into C2.   Doing more work again however, increasing the power usage for 20us (in this case) will make it change back into C1 again.  In other words; reducing the CPU core to a lower frequency takes a little more time, or else the OS would freeze too often.

This example, with two C3 states, makes it more difficult for the OSPM because now it needs to make decisions about when to use which register i.e. in this case 0x162 or 0x163.

But this is all from the top of my head (and I haven't checked it).  Time to get some sleep now

[FKA]

Master Chief, on Sep 7 2009, 06:39 AM, said:

But this is all from the top of my head (and I haven't checked it).  Time to get some sleep now

Many thanks Chief

D.

sk1nhd33t, on Sep 7 2009, 05:51 AM, said:

looking at the guide it's not as easy as copy paste to my DSDT unlike other guides out there..

question, anyone care to explain the advantage of this compared to voodoopower? ive seen only few members posting so im assuming not that much or really no one cared about speedstep and just happy they have OSX running.

Hi

It's not that straight forward and will take some time to get to grips with.
advantages|: using AppleIntelCPUPM, no need for disabler.kext, reported lower cpu temps, removes cst errors, closer to a vanilla build.

D.

[hackcat]

Are c-states processor dependent? Since I didn't have c-state tables on my mobo, I just borrowed from this thread. The more I think about it, my audio stutter could have been because I was rapidly dropping in and out of a c-state. If I did a bit more activity like moving the mouse a lot, the audio stopped stuttering. So the heuristics as when to idle or not were wrong for me, i.e playing audio was just at the threshold of when to drop into a c-state (perhaps even just C0) and the latency switch back and forth accounted for the stutter.