DSDT - Vanilla Speedstep - Generic Scope (_PR)

[mitch_de]

Thanks for MC to explain details !

But even with information:

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.

i dont understand what i must use for only having C1 state.

Can i change this:

(_CST, Package() 
       { 
	[b]3[/b],  [b]/// C1, C2,C3[/b]
	Package (0x04) {.... {Register (FFixedHW, 1, 2, 0x000)},1,1,1000}, 
	Package (0x04) {.... {Register (FFixedHW, 8, 0, 0x414)},2,1,500}, 
	Package (0x04) {.... {Register (FFixedHW, 8, 0, 0x415)},3,85,250} 
       })

into that ?

(_CST, Package() 
       { 
	[b]1[/b],  // only C1
	Package (0x04) {.... {Register (FFixedHW, 1, 2, 0x000)},1,1,1000}, 	
	Package (0x04) {.... {Register (FFixedHW, 8, 0, 0x414)},2,1,500}, 
	Package (0x04) {.... {Register (FFixedHW, 8, 0, 0x415)},3,85,250} 
       })

How much C-states has my C2D E7300 CPU (i think only has C1!!) .

Only newest mobile cpus + maybe newer desktop E8xxx, Q9xxx cpus have C2,c3;C4 for my knowledge.

Ans last but not least:

Doesnt also mainboard vendor (ACPI Bios) make differences which maybe cant be patched by dsdt changes ?

[blackosx]

Hi mitch. This whole subject is hard to grasp every detail in one go, so I have at least tried to understand just a few bits.

From what I have understood so far if you only want your processor to enter C1 then it should look something like this.

[size=2](_CST, Package() 
       { 
	[b]1[/b],  // only C1
	Package (0x04) {.... {Register (FFixedHW, 1, 2, 0x000)},1,1,1000}
       })[/size]

I have the same CPU as you, and I used a linux dump to generate my tables and it made me C0-C3 CST tables, so I guess we have 3 C-States? But don't take my word as Gospel as I am only very new to this

[keeza]

I have the same CPU as you, and I used a linux dump to generate my tables and it made me C0-C3 CST tables, so I guess we have 3 C-States? But don't take my word as Gospel as I am only very new to this

 

Look for this code in your SSDT CPUPM file from your ACPI dumps, for my processor there are 3 C-States. Example of CPU1:

 

Scope (\_PR.CPU1)
	   {
		   Name (HI1, 0x00)
		   Naod (_PDC, 1, NotSerialized)
		   {
			   CreateDWordField (Arg0, 0x08, CAP1)
			   Store (CAP1, PDC1)
			   If (LEqual (TLD1, 0x00))
			   {
				   If (LEqual (And (PDC1, 0x0A), 0x0A))
				   {
					   If (And (CFGD, 0x02))
					   {
						   OperationRegion (IST1, SystemMemory, DerefOf (Index (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05
							   )))
						   Load (IST1, HI1)
					   }

					   If (And (CFGD, 0x10))
					   {
						   OperationRegion (CST1, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B
							   )))
						   Load (CST1, HC1)
					   }

					   Store (0x01, TLD1)
				   }
			   }
		   }

 

The question I think that needs to be asked is: have we cut too much out from the SSDT? I mean when I compare my old SSDT with the new version my old one is about ten times the length. My old one also sees variation in voltage and multiplier between cores whereas the new one doesnt i.e. they switch but at the same voltage and multiplier.

 

So many unanswered questions.......

 

*EDIT*

 

Regarding this code from my current dsdt:

	   Scope (_PR.CPU1)
	{
		Method (_CST, 0, NotSerialized)
		{
			Return (Package (0x04)
			{
				0x03, 
				Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0x000, ,)},0x01,0x01,0x3E8}, 
				Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x414, ,)},0x02,0x01,0x1F4}, 
				Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x415, ,)},0x03,0x55,0x0FA} 
			})
		}
	}

 

Shouldn't the bottom two registers be SystemIO as posted here? The 414 and 415 values are system IO values no?

 

And can anyone shed some light on CFGD values?

[blackosx]

Here's the same section from my SSDT CPUPM acpidump for comparison. It looks identical to yours apart from the top Names and yours has Naod (_PDC where as mine has Method (_PDC. What's Naod?

Scope (\_PR.CPU1)
   {
       Name (HI1, 0x00)
       Name (HC1, 0x00)
       Name (TLD1, 0x00)
       Method (_PDC, 1, NotSerialized)
       {
           CreateDWordField (Arg0, 0x08, CAP1)
           Store (CAP1, PDC1)
           If (LEqual (TLD1, 0x00))
           {
               If (LEqual (And (PDC1, 0x0A), 0x0A))
               {
                   If (And (CFGD, 0x02))
                   {
                       OperationRegion (IST1, SystemMemory, DerefOf (Index (SSDT,
0x04)), DerefOf (Index (SSDT, 0x05
                           )))
                       Load (IST1, HI1)
                   }

                   If (And (CFGD, 0x10))
                   {
                       OperationRegion (CST1, SystemMemory, DerefOf (Index (SSDT,
0x0A)), DerefOf (Index (SSDT, 0x0B
                           )))
                       Load (CST1, HC1)
                   }

                   Store (0x01, TLD1)
               }
           }
       }
   }

But I don't yet understand it.

And as Keeza, I too ask about the SystemIO as opposed to FFixedHW, and the CFGD values?

(I know FormerlyKnownAs already replied that it didn't matter what values were used) It's just in the quest for understanding.

 

EDIT: I have attempted to work out what CFGD is and here's my basic attempt. CFGD is some memory address? (0x020383F2) in my case, declared in SSDT CpuPm, which is then used for checking which parts of the SSDT (CpunCst and CpunIst) data to work on. Then each SSDT CPUnCST checks a different bit (0x80, 0x40, 0x20) offset from CFGD to work out which C-State to use?.. (Though this might be totally incorrect, show absolutely nothing, and be a complete waste of time)

 

EDIT: I have just found an earlier post where MasterChief touches on this.. 'This code is responsible for loading the CST tables, on MB's with CST tables'.. But we are adding our own CST info in to our DSDT's now so I guess this is not relevant?

 

EDT: Maybe I need to take time out and read this whole thread properly from start to finish. I don't want to fill up this thread with repeat info if it's already been covered. As FormerlyKnownAs mentions he originally started with the MacPro SSDT supplied by Roisoft. And the start of this thread shows all SSDT info being used....

 

They both work yes. And there are indeed examples of simple _CST objects in the ACPI specifications, but there is a small difference, but in the end it all boils down to style preferences (nits) and readability. Whatever suits you best

Thanks. I will endeavour to learn.

(How the hell did you ever learn all this?)

[mitch_de]

Keeza: "look for this code in your SSDT CPUPM file from your ACPI dumps, for my processor there are 3 C-States. Example of CPU1:..:"

(this code : Posting above)

I cant see why+where there should be excat 3 C-Cstates in your ssdt code.

Where do you see that 3-Cstates in your ssdt code (to compare with mine) ?

[keeza]

Keeza: "look for this code in your SSDT CPUPM file from your ACPI dumps, for my processor there are 3 C-States. Example of CPU1:..:"

(this code : Posting above)

I cant see why+where there should be excat 3 C-Cstates in your ssdt code.

Where do you see that 3-Cstates in your ssdt code (to compare with mine) ?

 

I merely pointed this out for the purpose of finding out how many C-States your CPU supports. My Q9550 supports three C-States. It is not presently included in my most recent version of my dsdt which is based on mm67's and MC's work. My earlier versions did though and they can be found earlier in this thread (around page 11 I think).

 

You will find that info in your SSDT CPUPM file from your ACPI dump (if you have used Linux for your dumps then the original SSDT file will be named something like: SSDT_r1-PmRef-CpuPm-3000-INTL-20040311

[blackosx]

@mitch. If it helps, I think Keeza means this.

Check these earlier posts by ApexDE and FormlerlyKnownAs where they talk about having zero for address in SSDT.

 

For reference, here's mine. It's the addresses in red which identify the number of C-states. If they are blank then you don't have any. (I think that's correct).

 Name (SSDT, Package (0x18)
       {
           "CPU0IST ", 
           0xDFEEE580, 
           0x0000022A, 
           "CPU1IST ", 
           0xDFEEEA40, 
           0x00000152, 
           "[color="#4169E1"]CPU0CST[/color] ", 
           [color="#FF0000"]0xDFEEEBA0[/color], 
           0x0000018A, 
           "[color="#4169E1"]CPU1CST[/color] ", 
           [color="#FF0000"]0xDFEEED30[/color], 
           0x0000018A, 
           "CPU2IST ", 
           0x00000000, 
           0xF000E816, 
           "CPU3IST ", 
           0x00000000, 
           0xF000E816, 
           "[color="#4169E1"]CPU2CST[/color] ", 
           [color="#FF0000"]0xDFEEEEC0[/color], 
           0x0000018A, 
           "[color="#4169E1"]CPU3CST[/color] ", 
           [color="#FF0000"]0xDFEEF050[/color], 
           0x0000018A
       })

[Master Chief]

Thanks for MC to explain details !

 

...

 

i dont understand what i must use for only having C1 state.

You are welcome. Now. Let's get you going with C1. And I'll be using my DSDT for it as example. Here's a snippet from it for C1 support:

            Method (_CST, 0, NotSerialized) // Override Object.
           {
               Return (Package (0x02)
               {
                   One, // Number of C-State packages: 1 (C1).
                   Package (0x04)
                   {
                       ResourceTemplate ()
                       {
                           Register (FFixedHW, 
                               0x01,       // Bit Width
                               0x02,       // Bit Offset
                               0x00000000, // Address
                               0x01,       // Access Size
                               )
                       },
                       One, 
                       [color="#FF0000"]0x9D[/color], 
                       0x03E8
                   }, 
               })
           }

And note the one in red. That's the latency value blocking it from entering (trying to enter) C2 and thus deeper C states. Add this code and point to it, from the other Processors definition blocks like this:

		Processor (CPU1, 0x02, 0x00000810, 0x06)
	{
		Alias (\_PR.CPU1._PSS, _PSS)
		Alias (\_PR.CPU1._CST, _CST)
	}

That'll do the trick. And yes not every MB has C2+ support due to the fact that hardware support is required (apparently).

 

I hope this helps, and if not keep bugging people here – everyone should at least try to help other people after all

 

Edit: You don't necessarily need CFGD. Nope. And a number of people here no longer use it – with either Asus or GB boards. Some of us aren't even loading SSDT tables anymore. But having a board with C2+ support makes things a little more complicated. It however also gives you the possibility of checking your _CST changes with Linux

 

@blackosx: I just happen to be a developer, and I read a lot – and so could you if you have enough time for it.

 

Happy Hacking!

[mitch_de]

Thanks ! I will try that and report .

I´ll be back - hoping so

 

break:

Thanks to blackosx for showing ssdt with those hex values 0 in red if C-State is aktive/found (his post above).

 

I looked before made changes in my ssdt (orig. without dsdt injection at boottime). GA-EP35-DS3 (NO L, NO R, NO P)

 

Found that the CPU0/1 CST with 00000000 vs blackosx non zeros.

So no C-State computed by bios for my E7300 CPU, for my understanding looking in my ssdt.

Better NOT to use Cstate dsdt injection ?

 

But i have those CPUxIST with non zero values. What was that for ? i forgot, sorry

 

   Scope (\)
   {
       Name (SSDT, Package (0x18)
       {
           "CPU0[b]IST[/b] ", 
           0xDFEE7F00, 
           0x0000022A, 
           "CPU1IST ", 
           0xDFEE83C0, 
           0x00000152, 
           "CPU0[b]CST[/b] ", 
         [b]  [color="#FF0000"]0x00000000[/color], [/b]   // blackosx has no zeros here
           0xF000E816, 
           "CPU1[b]CST[/b] ", 
          [b] [color="#FF0000"]0x00000000[/color], [/b]  // blackosx has no zeros here
           0xF000E816, 
           "CPU2IST ", 
......
       })
       Name (CFGD, [color="#FF0000"]0x02030302[/color])
       Name (\PDC0, 0x80000000)
       Name (\PDC1, 0x80000000)
       Name (\PDC2, 0x80000000)
       Name (\PDC3, 0x80000000)
   }

[kdawg]

I want to reiterate my earlier post about synchronus vs asyncronus processor function. I feel like a large portion of the community think their C & P states are working properly. But it's been made clear that when they've been implemented properly each core operates independantly. The reason I say this is because most of the VoodooMonitor screenshots show all cores working syncronusly.

 

Can someone help clear this up with screenshots or other methods of proper verification.

[Master Chief]

I want to reiterate my earlier post about synchronus vs asyncronus processor function. I feel like a large portion of the community think their C & P states are working properly. But it's been made clear that when they've been implemented properly each core operates independantly. The reason I say this is because most of the VoodooMonitor screenshots show all cores working syncronusly.

 

Can someone help clear this up with screenshots or other methods of proper verification.

It's a good question. And one that should be answered. However, I still need to figure out the how, what et all.

 

And what I see here is that the voltage of core 0/1 and 3/4 are going hand in hand i.e. I see both of them change (two cores in one package). And sometimes all cores change, but it is important that you see two of them change simultaneously (with a four core CPU that is).

 

If you see the voltage change of two cores, then I believe that your on the right track. And I think that both CPU-i and VoodooMonitor are missing updates, but I have to look into it before I start blaming other people for it. That wouldn't be fair.

 

I am also working on a few other changes first, of which I hope to share results soon. It's just that everything is taking a lot of time. This is however no excuse for not replying earlier, just an observation and explanation. Not to mention that this is just a hobby of course

 

Happy Hacking!

[kdawg]

And what I see here is that the voltage of core 0/1 and 3/4 are going hand in hand i.e. I see both of them change (two cores in one package). And sometimes all cores change, but it is important that you see two of them change simultaneously (with a four core CPU that is).

 

If you see the voltage change of two cores, then I believe that your on the right track. And I think that both CPU-i and VoodooMonitor are missing updates, but I have to look into it before I start blaming other people for it. That wouldn't be fair.

I guess the best solution would be to observe a real Mac with 4 cores, if I knew someone that had a Mac with 4 cores. I suppose that would help clear things up.

 

I am also working on a few other changes first, of which I hope to share results soon. It's just that everything is taking a lot of time. This is however no excuse for not replying earlier, just an observation and explanation.

No pressure... of course. The question wasn't aimed at anyone in particular.

 

Not to mention that this is just a hobby of course

One that tends to consume people like an addiction... me included. Cheers!

[Master Chief]

...

 

Found that the CPU0/1 CST with 00000000 vs blackosx non zeros.

So no C-State computed by bios for my E7300 CPU, for my understanding looking in my ssdt.

Better NOT to use Cstate dsdt injection ?

 

But i have those CPUxIST with non zero values. What was that for ? i forgot, sorry

You don't have a C1 setting in your BIOS? Are others here using the same MB/BIOS? If yes, what are their findings? I mean maybe you are missing something.

 

Also, C1 is usually supported, and on most modern motherboards. Should not be a problem. And about that IST vs CST thing: IST is usually used for P-State support and CST wel you get the drill.

 

p.s. Adding the provided code should show you a drop of about 5 degrees.

[blackosx]

So no C-State computed by bios for my E7300 CPU, for my understanding looking in my ssdt.

Hi mitch_de

 

In the advanced BIOS settings of my motherboard there is support for EIST and C-states which I have enabled. Is that the same for your mobo?

[mitch_de]

Thanks!. My MB is GA-EP35-DS3 . BIOS F4. C1E in BIOS Setting enabled Fine if someone has excat same MB.

I started early with DSDT things so i remembered that ssdt hasnt C-States, also with older BIOS, and so now i was a bit more slow with "using all i can find" on dsdt code sniples here

And that is also my way of trying first to use only C1 State , if my bios ssdt not even one active.

I will try now that C1 only setting with that chameleon flag for using it. and report back.

If that not works - no problem. My C2D even OC didnt get any hot - idle (no powermanagement at all) less than 40 Celsius, max cpu load

I am not sure but that real 5 Celsius lowering with correct C-States are ONLY if using AppleIntelCPU.kext. If not using that .kext with not correct / unknown C-state settings ,your Celisus is also lower=same als with working AppleIntelCPU+correct C-states.

Last Q: Do i understand ssdt table correct, that some ssdt values changes on cpu change (same MB , new cpu type) = ssdt values are dynamic/can change and not fixed like dsdt table ?

[keeza]

@mitch. If it helps, I think Keeza means this.

 

This is what I was referring to (my SSDT_r1-PmRef-CpuPm):

 

    External (\_PR_.CPU3, DeviceObj)
   External (\_PR_.CPU2, DeviceObj)
   External (\_PR_.CPU1, DeviceObj)
   External (\_PR_.CPU0, DeviceObj)

   Scope (\)
   {
       Name (SSDT, Package (0x18)
       {
           "CPU0IST ", 
           0xCFEE7F10, 
           0x0000022A, 
           "CPU1IST ", 
           0xCFEE83D0, 
           0x00000152, 
           "CPU0CST ", 
[color="#ff0000"]            0xCFEE87F0,[/color]   [color="#ff0000"]// Four C-states[/color]
           0x0000018A, 
           "CPU1CST ", 
[color="#ff0000"]            0xCFEE8980,[/color] 
           0x0000018A, 
           "CPU2IST ", 
           0xCFEE8530, 
           0x00000152, 
           "CPU3IST ", 
           0xCFEE8690, 
           0x00000152, 
           "CPU2CST ", 
[color="#ff0000"]            0xCFEE8B10,[/color] 
           0x0000018A, 
           "CPU3CST ", 
[color="#ff0000"]            0xCFEE8CA0, [/color]
           0x0000018A
       })
       Name (CFGD, 0x040383F2)
       Name (\PDC0, 0x80000000)
       Name (\PDC1, 0x80000000)
       Name (\PDC2, 0x80000000)
       Name (\PDC3, 0x80000000)
   }

   Scope (\_PR.CPU0)
   {
       Name (HI0, 0x00)
       Name (HC0, 0x00)
       Name (TLD0, 0x00)
       Method (_PDC, 1, NotSerialized)
       {
           CreateDWordField (Arg0, 0x08, CAP0)
           Store (CAP0, PDC0)
           If (LEqual (TLD0, 0x00))
           {
               If (LEqual (And (PDC0, 0x0A), 0x0A))
               {
                   If (And (CFGD, 0x02))
                   {
                       OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02
                           )))
                       Load (IST0, HI0)
                   } [color="#ff0000"]Note: No load CST 0 here!
 [/color]

                   Store (0x01, TLD0)
               }
           }
       }
   }

   Scope (\_PR.CPU1)
   {
       Name (HI1, 0x00)
       Name (HC1, 0x00)
       Name (TLD1, 0x00)
       Method (_PDC, 1, NotSerialized)
       {
           CreateDWordField (Arg0, 0x08, CAP1)
           Store (CAP1, PDC1)
           If (LEqual (TLD1, 0x00))
           {
               If (LEqual (And (PDC1, 0x0A), 0x0A))
               {
                   If (And (CFGD, 0x02))
                   {
                       OperationRegion (IST1, SystemMemory, DerefOf (Index (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05
                           )))
                       Load (IST1, HI1)
                   } 
                   If (And (CFGD, 0x10))
                   {
                       OperationRegion (CST1, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B
                           )))
[color="#ff0000"]                        Load (CST1[/color], HC1)
                   }

                   Store (0x01, TLD1)
               }
           }
       }
   }

   Scope (\_PR.CPU2)
   {
       Name (HI2, 0x00)
       Name (HC2, 0x00)
       Name (TLD2, 0x00)
       Method (_PDC, 1, NotSerialized)
       {
           CreateDWordField (Arg0, 0x08, CAP2)
           Store (CAP2, PDC2)
           If (LEqual (TLD2, 0x00))
           {
               If (LEqual (And (PDC2, 0x0A), 0x0A))
               {
                   If (And (CFGD, 0x02))
                   {
                       OperationRegion (IST2, SystemMemory, DerefOf (Index (SSDT, 0x0D)), DerefOf (Index (SSDT, 0x0E
                           )))
                       Load (IST2, HI2)
                   }

                   If (And (CFGD, 0x10))
                   {
                       OperationRegion (CST2, SystemMemory, DerefOf (Index (SSDT, 0x13)), DerefOf (Index (SSDT, 0x14
                           )))
[color="#ff0000"]                        Load (CST2[/color], HC2)
                   }

                   Store (0x01, TLD2)
               }
           }
       }
   }

   Scope (\_PR.CPU3)
   {
       Name (HI3, 0x00)
       Name (HC3, 0x00)
       Name (TLD3, 0x00)
       Method (_PDC, 1, NotSerialized)
       {
           CreateDWordField (Arg0, 0x08, CAP3)
           Store (CAP3, PDC3)
           If (LEqual (TLD3, 0x00))
           {
               If (LEqual (And (PDC3, 0x0A), 0x0A))
               {
                   If (And (CFGD, 0x02))
                   {
                       OperationRegion (IST3, SystemMemory, DerefOf (Index (SSDT, 0x10)), DerefOf (Index (SSDT, 0x11
                           )))
                       Load (IST3, HI3)
                   }

                   If (And (CFGD, 0x10))
                   {
                       OperationRegion (CST3, SystemMemory, DerefOf (Index (SSDT, 0x16)), DerefOf (Index (SSDT, 0x17
                           )))
[color="#ff0000"]                        Load (CST3,[/color] HC3)
                   }

                   Store (0x01, TLD3)
               }
           }
       }
   }
}

 

I did actually mention that I had 3 C-States but I actually have four - CST0 is the normal CPU operating mode whereby the CPU is 100% on.

 

The other three C-States (I assume) after checking BIOS are as follows:

CST1 = C1E

CST2 = C2/C2E

CST3 = C4/C4E

 

CST1&2 relate to clock speed (processor speed)

CST3 relates to voltage drop

 

I have clock speed reduction and voltage (and therefor temp) reduction working.

 

But they only work on all four cores simultaneously as kdawg mentioned.

 

However if you look at the above code it contains if/then instructions for each core to enter a particular C-State. If my assumption is correct then this is what is missing - instructions to each core to enter a particular C-State under a given circumstance. Is this the missing link?

 

I, of course, could be totally wrong, don't be afraid to say so if I am - I'm learning too!

 

Further reading link provided by a previous poster

 

*EDIT*

 

A couple of snaps of voltage changes between cores - only works in pairs, frequency does too but happens too quickly therefore unable to "Grab" it.

[mitch_de]

If (And (CFGD, 0x10))
                   {
                       OperationRegion ([color="#FF0000"]CST1[/color], SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B
                           )))
                       Load ([color="#FF0000"]CST1[/color], HC1)
                   }

 

Hi, i think you make an wrong logical connecting your CST1 ..CST3 (or CST0 ..3 on other MBs) ssdt variables with real C_states.

All CST0 - CST3 variables could named Pete0..Pete3 with same function. But i can be wrong.

That CST1 ..CST3 (or CST0 ..3 on other MBs) , i believe are connected to the CPU numbers 0 ..3 and are not an sign of C1-C4 States.

I think the sign of which C-States are available are only in that code below, not in the first code box section above.

 Name (SSDT, Package (0x18)
       {
....          "[b]CPU0CST[/b] ", 
           0xCFEE87F0,   // Four C-states  // YEP ! , in my case here zeros = no C1...
           0x0000018A, 
           "CPU1CST ", 
           0xCFEE8980, 
           0x0000018A, 
         [size=1]  "CPU2IST ", 
           0xCFEE8530, 
           0x00000152, 
           "CPU3IST ", 
           0xCFEE8690, 
           0x00000152, 
           "CPU2CST ", 
           0xCFEE8B10, 
           0x0000018A, 
           "CPU3CST ", 
           0xCFEE8CA0, 
           0x0000018A[/size]
       })

 

 

Some of the SSDT heros here will tell us whats right soon

Its so great to get an rised learning curve by that ssdt heros here!

[Cathul]

Hi mitch_de

 

In the advanced BIOS settings of my motherboard there is support for EIST and C-states which I have enabled. Is that the same for your mobo?

The older P35-boards like mitch_de and i have don't provide so many options in regards to cpu power management.

I have a GA-P35-DS3 Rev. 1.0 and don't have an option for EIST in my bios.

[blackosx]

Last Q: Do i understand ssdt table correct, that some ssdt values changes on cpu change (same MB , new cpu type) = ssdt values are dynamic/can change and not fixed like dsdt table ?

Yes, I guess so mitch_de. I think SSDT info is dependent on both the Mobo & CPU.

 

If my assumption is correct then this is what is missing - instructions to each core to enter a particular C-State under a given circumstance. Is this the missing link?

I am inclined to agree with you in theory of separate code for each CPU, but I need more time to read and to try to understand it more. (There is so much info to consume!)

EDIT: I still want to look more in to the CFGD choices I asked about here. But some of this ground has been covered before by Brett Whinnen, Master Chief & yeehaa back on pages 9-11... (I am going round in circles!)

[kdawg]

I have clock speed reduction and voltage (and therefor temp) reduction working.

 

But they only work on all four cores simultaneously as kdawg mentioned.

 

However if you look at the above code it contains if/then instructions for each core to enter a particular C-State. If my assumption is correct then this is what is missing - instructions to each core to enter a particular C-State under a given circumstance. Is this the missing link?

 

I, of course, could be totally wrong, don't be afraid to say so if I am - I'm learning too!

 

Further reading link provided by a previous poster

 

*EDIT*

 

A couple of snaps of voltage changes between cores - only works in pairs, frequency does too but happens too quickly therefore unable to "Grab" it.

Somebody somewhere must have access to a real Quad core mac. That would help shed some light.

 

Kudos on the screensnaps keeza! I tried for nearly half an hour to get one of mine showing the change in voltage. After talking to MasterChief and Mojodojo I went back and took a peek at VoodooMonitor again and I in fact get the same behavior. My voltages operate in pairs independently, however it happens faster than I can't get a screenshot of it. Perhaps that why I didn't notice it before, I was more focused on the multiplier.

 

I glad we got people thinking about it.

 

keeza, are the transitions slow enough where you didn't have a problem getting the screenshot? Mine happen VERY quickly.

 

 

The older P35-boards like mitch_de and i have don't provide so many options in regards to cpu power management.

I have a GA-P35-DS3 Rev. 1.0 and don't have an option for EIST in my bios.

I think that would be the GA-EP35-DS3. E=Dynamic Energy Saver. I had a EP35-DS4 with an EIST option.

[blackosx]

Somebody somewhere must have access to a real Quad core mac. That would help shed some light.

I know someone who I think has a MacPro, I will have to contact them and see if they will let me play?...

If I can get the chance, what would be the main things you want me to gather? Because if I can get on it, I might only have one chance to play?

Let me know then I'll load my USB stick with apps (IOregistryExplorer, etc and do some detective work).

[keeza]

Somebody somewhere must have access to a real Quad core mac. That would help shed some light.

keeza, are the transitions slow enough where you didn't have a problem getting the screenshot? Mine happen VERY quickly.

 

I have access to a macpro3,1 dsdt but I'm not sure if it's fully genuine i.e. hasn't been doctored up hence why I haven't posted it.

 

It took several attempts to get the screenshots of the voltages but I gave up on the frequency as its too quick. But it definetly changes in pairs at times.

 

Any thoughts on one of my previous posts re system IO values? here

[blackosx]

Any thoughts on one of my previous posts re system IO values? here

Oh yeah. I looked at MasterChief's DSDT v3.0 from the P5K pro and he is using SystemIO so I changed mine too and it works fine (as in I don't notice any difference to when it was previously FFixedHW).

 

This is my current trial Scope(_PR)'s that I am currently using..

Scope (_PR)
   {
       Processor (CPU0, 0, 0x00000410, 6) {}
       Processor (CPU1, 1, 0x00000410, 6) {}
   }

   Scope (_PR.CPU0)
   {
Method (_PSS, 0, NotSerialized)
{
	Return (Package(0x05)
	{
		Package (0x06) { 2660, 0, 10, 10, 0x0A1D, 0 },
		Package (0x06) { 2394, 0, 10, 10, 0x091C, 1 },
		Package (0x06) { 2128, 0, 10, 10, 0x081C, 2 },
		Package (0x06) { 1862, 0, 10, 10, 0x071B, 3 },
		Package (0x06) { 1596, 0, 10, 10, 0x61B8, 4 }
	})
}
       Method (_CST, 0, NotSerialized)
       {
	Return (Package (0x04)
	{
		0x03, 
		Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x000)},1,1,1000}, 
		Package (0x04) {ResourceTemplate () {Register (SystemIO, 8, 0, 0x414)},2,90,500}, // latency from FACP table
		Package (0x04) {ResourceTemplate () {Register (SystemIO, 8, 0, 0x415)},3,180,250} // latency from FACP table
	})
       }
   }

   Scope (_PR.CPU1) 
   {
           Alias (\_PR.CPU0._PSS, _PSS)
           Alias (\_PR.CPU0._CST, _CST)
   }

[DieBuche]

I just realized that i get Kernel Panics on high load with speedstep enabled!

I have four pstates (6-9), they change independently, all seems fine, until i have 100% load for a while.

First i thought it was Handbrakes fault, then i tried streesing my rig with yes > /dev/null and panicked after 5 min.

It is definetly not an overheating issue (all tools report 50-55 on load, and i even put my pc into the cold (around zero degrees celsius..) still the same.

 

I removed the ssdt part, voila it worked.

I put back the original pstates i extracted –KP.

I increased the voltage in the tables (as a cpu might have errors when the vcore is to low)– still panics.

 

My dsdt is attached, specs in the sig. Anyone got an idea why?

dsdt.dsl.zip

[FKA]

If (And (CFGD, 0x10))
                   {
                       OperationRegion ([color="#ff0000"]CST1[/color], SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B
                           )))
                       Load ([color="#ff0000"]CST1[/color], HC1)
                   }

 

Hi, i think you make an wrong logical connecting your CST1 ..CST3 (or CST0 ..3 on other MBs) ssdt variables with real C_states.

All CST0 - CST3 variables could named Pete0..Pete3 with same function. But i can be wrong.

That CST1 ..CST3 (or CST0 ..3 on other MBs) , i believe are connected to the CPU numbers 0 ..3 and are not an sign of C1-C4 States.

I think the sign of which C-States are available are only in that code below, not in the first code box section above.

 Name (SSDT, Package (0x18)
       {
....          "[b]CPU0CST[/b] ", 
           0xCFEE87F0,   // Four C-states  // YEP ! , in my case here zeros = no C1...
           0x0000018A, 
           "CPU1CST ", 
           0xCFEE8980, 
           0x0000018A, 
         [size=1]  "CPU2IST ", 
           0xCFEE8530, 
           0x00000152, 
           "CPU3IST ", 
           0xCFEE8690, 
           0x00000152, 
           "CPU2CST ", 
           0xCFEE8B10, 
           0x0000018A, 
           "CPU3CST ", 
           0xCFEE8CA0, 
           0x0000018A[/size]
       })

 

 

Some of the SSDT heros here will tell us whats right soon

Its so great to get an rised learning curve by that ssdt heros here!

 

Hi mitch

 

I've talked about this a lot further up the thread.

 

I also have a memory address of 0000000 for my _cst tables and only have an option for C1E in BIOS.

 

I have assumed this means no c-states - and indeed my idle CPU temp is higher than some here have reported - around 38-43.C

 

However - with the cst data from either a MP3,1 or another hack that supports C1, C2 etc I do appear to enter a C1 state.

vCore drops below that of my lowest multi (sometimes only for a few seconds but it does happen.~)

 

D.