DSDT fixes for Gigabyte boards

[mitch_de]

Donet forget me

AppleIntelCPU trotthling works with my PStates (Cstate1). But compard to voodoopower ist stays on CPU load around 20% on slowest MHz whereas i configures voodoopower (by that threshooudsetting) switches up to next higher MHz.

me: mitch_de @ Oct 25 2009, 05:41 PM)

Sorry, i mean how can i adjust the AppleIntelCPU stepping up/downs threshoot . My Pstates are already fully working + correct.

But i want to change the threshoot / make AppleIntelCPU switch earlier (on less cpu %) to higher MHZ.

You'll have to change the latency for this. MatthewL can help you with this. Right Matthew?

But isnt latency (you meaned that in Pstates PSS definition) right my case : want to earlier switch up Mhz on lower cpu % loads ?

I thought that this latency means how often the state will be checked but not at which cpu load it will switch up / down.

Is that cpu load % > switch up / down somewhere (ACPIFamilyPlugin .plist) defined ?

 

I now use voodoopower again, because AppleIntelCPU does for me to much powersaving = some system slowness on lower cpu loads.

[mm67]

Ok. Great work. Thanks! And my (educated) guess would be to use something like this:

LoadTable("SSDT", "PmRef", "CpuPm")

instead of Load(). I am however currently unable to verify this myself. Any takers?

 

Ok, I believe that we can somehow load the Pm table dynamically this way, but I still can't figure out why you want to load it in the first place. It makes sense to load tables of Asus or MSI or something else that has something in Pm table and IST tables. But take a look at a Gigabyte IST table, there is nothing worth loading there if you have already loaded a handmade PSS table. Same applies to CST table. And Pm table just has definitions for PDC(x) or CFGD variables, you can just as well add them manually to PR scope. If you are trying to build a universal DSDT for any board then this makes sense, for GB boards alone this isn't necessary.

[FKA]

Donet forget me

 

I'm following you mitch.

I dont have your answer though!

[Master Chief]

Ok, I believe that we can somehow load the Pm table dynamically this way, but I still can't figure out why you want to load it in the first place. It makes sense to load tables of Asus or MSI or something else that has something in Pm table and IST tables. But take a look at a Gigabyte IST table, there is nothing worth loading there if you have already loaded a handmade PSS table. Same applies to CST table. And Pm table just has definitions for PDC(x) or CFGD variables, you can just as well add them manually to PR scope. If you are trying to build a universal DSDT for any board then this makes sense, for GB boards alone this isn't necessary.

You may not want to load the IST/CST tables – which we discussed earlier here – but we need that _PDC method, the one called by OSPM with the capability data. At least I do (see note below).

 

Note: The rise in temperature without a _PDC method (see DSDT - Vanilla Speedstep thread) was simply unacceptable for me.

 

Not to mention that I already smoked a perfectly good functioning Intel CPU. And I am not going to be held responsible for more disaster – we're also talking about other peoples wallets after all. Maybe that is why I play it safe (better safe than sorry) but I will keep the blocks loaded, just like the ACPI developers meant it to be (I don't believe that any of them were wasting their time).

[mm67]

You may not want to load the IST/CST tables �€“ which we discussed earlier here �€“ but we need that _PDC method, the one called by OSPM with the capability data. At least I do (see note below).

 

Note: The rise in temperature without a _PDC method (see DSDT - Vanilla Speedstep thread) was simply unacceptable for me.

 

Not to mention that I already smoked a perfectly good functioning Intel CPU. And I am not going to be held responsible for more disaster �€“ we're also talking about other peoples wallets after all. Maybe that is why I play it safe (better safe than sorry) but I will keep the blocks loaded, just like the ACPI developers meant it to be (I don't believe that any of them were wasting their time).

GB PDC

        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)
                   }

                   Store (0x01, TLD0)
               }
           }
       }

 

MSI PDC

        Method (_PDC, 1, NotSerialized)
       {
           CreateDWordField (Arg0, 0x00, REVS)
           CreateDWordField (Arg0, 0x04, SIZE)
           Store (SizeOf (Arg0), Local0)
           Store (Subtract (Local0, 0x08), Local1)
           CreateField (Arg0, 0x40, Multiply (Local1, 0x08), TEMP)
           Name (STS0, Buffer (0x04)
           {
               0x00, 0x00, 0x00, 0x00
           })
           Concatenate (STS0, TEMP, Local2)
           _OSC (Buffer (0x10)
               {
                   /* 0000 */    0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, 
                   /* 0008 */    0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53
               }, REVS, SIZE, Local2)
       }

 

Does it look like GB PDC is doing something useful, I totally agree on MSI or Asus but GB, there is nothing.

 

/edit

Was jus checking the Acpispec and found this about LoadTable. "OSPM loads the DSDT and all SSDTs during initialization. As such, Definition Blocks to be conditionally loaded via LoadTable must contain signatures other than “SSDT”." Maybe this will cause problems for your dynamical loading of tables.

[keeza]

That CFGD value should be okay, your SSDT tables are almost identical to mine.

But anyway, I'll show you how to calculate that value by yourself. Let's look

at your IST table and PSS method, looks like this:

        Method (_PSS, 0, NotSerialized)
       {
           If (LEqual (And (CFGD, 0x00060000), 0x00020000))
           {
               Return (SPSS)
           }

           If (LEqual (And (CFGD, 0x00060000), 0x00040000))
           {
               Return (NPSS)
           }

           If (LOr (And (CFGD, 0x4000), And (CFGD, 0x00010000)))
           {
               Return (NPSS)
           }

           Return (SPSS)
       }

 

That first comparison loads SPSS table if bit 17 is set and bit 18 is off, default value of 0x040383F2

has that so SPSS table is loaded, and we don't want that since it has unusable values.

 

If that first comparison failed then next one checks if bit 18 is set and bit 17 is off, 0x040483F2 has that so NPSS is loaded. 0x040583F2 would also do the same.

 

If the second comparison also failed then the last comparison checks for bits 14 and 16, if one or both are set then NPSS table is loaded. So for example 0x040183F2 would be a good value since it has bit 16 set and 0x0400C3F2 for example would have bit 14 set.

 

Then, if even this last comparison failed SPSS is loaded.

 

So there are many choices for CFGD value, you just have to check all places where that value is used so you don't use a value that disables something else.

 

 

So a working stripped down SSDT, including _PSS table (which can be modified to suit one's processor and number of P-States) is the goal here right? By working I mean switching multi's and voltage and Mhz.

 

I'll digest the above info, thanks for that, I've tried both 40483F2 and 40383F2 and no go with either.

What that means is that for me anyway, I have to have my full (long) SSDT incorporated in my dsdt to get working P-States.

My goal is to get the short SSDT in the dsdt that MC kindly edited for me to work.

 

So I'll try a few more things today.

[tapper00`]

@mm67 Could you take a look at this SSDT that I pulled from the EP35 board with Q9550?

 

The CFGD value is 0x04030302. I am trying to incorporate your CST info into my DSDT, but use as much from my SSDT as possible. I know you stated that you changed the CFGD value in yours.

 

Also, under the Name (SSDT, package (0x18) section, look at the values for CPU0CST through CPU3CST. Doesn't look right to me.

ssdt.dsl.zip

[xopher]

@ mm67,

 

Have you done any more modifications to your DSDT since 'stripped3.dsl' ? I'd love it if you'd continue to post all your updates here! Just eager to try them out

[mm67]

@mm67 Could you take a look at this SSDT that I pulled from the EP35 board with Q9550?

 

The CFGD value is 0x04030302. I am trying to incorporate your CST info into my DSDT, but use as much from my SSDT as possible. I know you stated that you changed the CFGD value in yours.

 

Also, under the Name (SSDT, package (0x18) section, look at the values for CPU0CST through CPU3CST. Doesn't look right to me.

 

Those are normal values for CST tables when you only have C1 enabled in bios. And it doesn't matter since we can't use native C-states anyway.

 

I don't have your IST tables so I can't tell for sure but 0x04050302 might be usable. You also have to change these lines

If (LEqual (And (PDC0, 0x0A), 0x0A))

into

If (LEqual (And (PDC0, 0x09), 0x09))

 

With those changes you might be able to load IST tables and get native P-states.

 

@ mm67,

 

Have you done any more modifications to your DSDT since 'stripped3.dsl' ? I'd love it if you'd continue to post all your updates here! Just eager to try them out

 

I haven't done anything major, just some cleaning up of PR scope. This is what I am using right now.

dsdt.dsl.zip

 

Would be really great if MC's idea of using LoadTable could be used, then I could get rid of those IST table addresses.

 

I'm not 100 % sure about that CST yet, I don't see any difference to old method, but please report if you do.

[Master Chief]

<snip />

 

Does it look like GB PDC is doing something useful, I totally agree on MSI or Asus but GB, there is nothing.

I first need to see a document which states that it is safe to remove this part. Having it working under OS X doesn't mean it is really functional. In fact it might slowly kill your CPU without having a clue. Not good.

 

/edit

Was jus checking the Acpispec and found this about LoadTable. "OSPM loads the DSDT and all SSDTs during initialization. As such, Definition Blocks to be conditionally loaded via LoadTable must contain signatures other than “SSDT”." Maybe this will cause problems for your dynamical loading of tables.

I checked and it works here, so what page/document is that?

[xopher]

I haven't done anything major, just some cleaning up of PR scope. This is what I am using right now.

dsdt.dsl.zip

 

Have you changed something in your Device (HDEF)? Sound didn't work anymore with that, had to revert to the old sound code. Are you using the LegacyHDA.kext or not? Oh, and do you have headphone auto-detection working? Eg. from the front panel.

 

Thanks and good work!

[mm67]

I first need to see a document which states that it is safe to remove this part. Having it working under OS X doesn't mean it is really functional. In fact it might slowly kill your CPU without having a clue. Not good.

 

 

I checked and it works here, so what page/document is that?

 

Acpispec40.pdf, page 613 or Acpispec30b, page 498. If you got it to load a SSDT table that's great, could you please show me an example.

 

Have you changed something in your Device (HDEF)? Sound didn't work anymore with that, had to revert to the old sound code. Are you using the LegacyHDA.kext or not? Oh, and do you have headphone auto-detection working? Eg. from the front panel.

 

Thanks and good work!

 

I don't use onboard audio, I was just experimenting with different configurations to see which one gives least error messages. You should absolutely use your own working HDEF configuration.

[VCH888]

@ mm67 or @ Master Chief

 

Could you explain me the following codes? What are these codes working for? I saw these in Device (PEX5) section from mm67's dsdt. I have two GB mainboards. EP35-DS3P has ethernet in Device (PEX5) and EP45-UD3R has ethernet in Device (PEX4).

 

Thank you.

 

               OperationRegion (PCTL, PCI_Config, 0x48, 0x04)
               Field (PCTL, ByteAcc, NoLock, Preserve)
               {
                           Offset (0x01), 
                   HPGE,   1, 
                           Offset (0x02), 
                           Offset (0x03), 
                           Offset (0x04)
               }

               OperationRegion (PSTS, PCI_Config, 0x8C, 0x04)
               Field (PSTS, ByteAcc, NoLock, Preserve)
               {
                           Offset (0x02), 
                   PMES,   1, 
                           Offset (0x04)
               }

               Method (_INI, 0, NotSerialized)
               {
                   If (LNotEqual (BPHP, 0x05))
                   {
                       Store (One, HPGE)
                   }
               }

[iSoprano]

@MC, @mm67, any idea as to what's the equivalent of PBLG and PBLS for GB boards? I tried so many things but the monitor doesn't come back after sleep. May be this will help

 

 

 

 

Method (WAK, 1, NotSerialized) //WAKE up

{

\_SB.PCI0.SBRG.EC0.EC0W (Arg0)

\_SB.PCI0.NWAK (Arg0)

\_SB.PCI0.SBRG.SWAK (Arg0)

LPWK (Arg0)

Store(\_SB.ATKD.PBLG(),local0) //---> Get Brightness level from NVS

\_SB.ATKD.PBLS(local0) //---> Set Brightness level.

}

[mm67]

Just found out a way to run native C-states and P-states, this one needs DropSSDT=no.

dsdt.dsl.zip

 

/edit

Checked again, only native C-states are working now, will try to make P-states work too. Temps are almost same with C-states only.

/edit2

This one has also native P-states working, but doesn't look as nice.

dsdt_tmp.dsl.zip

 

This one has native C-states and a handmade PSS table

pstates.dsl.zip

[Master Chief]

Acpispec40.pdf, page 613 or Acpispec30b, page 498. If you got it to load a SSDT table that's great, could you please show me an example.

Here's a quick note (I have to go in 5 minutes): I was hoping for someone with a GB board to confirm my previous finding, and here's what I use right now:

            Method (_OSC, 4, NotSerialized) // Operating System Capabilities
           {
               CreateDWordField (Arg3, 0x04, CAP1)
               Or (And (TYPE, 0x7FFFFFFF), CAP1, TYPE)

               If (LAnd (LEqual (And (TYPE, 0x09), 0x09), LNot (And (TBLD, One))))
               {
                   Or (TBLD, One, TBLD) // Remember this load – don't load it again when PNOT() notifications trigger a re-evaluation.
                   Load (STBL, HNDL)
                   // LoadTable ("SSDT", "AMI", "CPU1PM")
               }

               Return (Arg3)
           }

Please give LoadTable () a try and let me know if this works for you. Thanks.

[mm67]

Here's a quick note (I have to go in 5 minutes): I was hoping for someone with a GB board to confirm my previous finding, and here's what I use right now:

 

Please give LoadTable () a try and let me know if this works for you. Thanks.

 

Table header looks like this:

 * Original Table Header:
*     Signature        "SSDT"
*     Length           0x0000022A (554)
*     Revision         0x01
*     Checksum         0x31
*     OEM ID           "PmRef"
*     OEM Table ID     "Cpu0Ist"
*     OEM Revision     0x00003000 (12288)
*     Compiler ID      "INTL"
*     Compiler Version 0x20040311 (537133841)

 

So I am trying to load like this:

LoadTable("SSDT", "PmRef", "Cpu0Ist")

 

Doesn't seem to be working.

[mm67]

As you can see P-states and C-states are working

 

Only problem is that I currently have all Eist and C-state settings disabled in bios, so how is this possible with this dsdt.

All I can think is that OS X has all those C-state and P-settings built-in, it only checks the first cpu for valid CST and PSS tables. If it sees those then it discards them and starts using built-in values. Maybe someone has a better explanation for all this ?

 

This is all the code I need for P-states and C-states.

    Scope (_PR.CPU0)
   {
       Method (_CST, 0, NotSerialized)
       {
           Return (Package (0x04)
           {
               0x03, 
               Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0, ,)},0x01,0,0}, 
               Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0, ,)},0x02,0,0}, 
               Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0, ,)},0x03,0,0}, 
           })
       }
    Method (_PSS, 0, NotSerialized)
	{
		Return (Package(0x02)
			{
			Package (0x06) { 0, 0, 0, 0, 0x4820, 0 },
			Package (0x06) { 0, 0, 0, 0, 0x616, 1 }
			})
	}
   }

 

If someone isn't lucky enough to have correct device-id for LPCB built-in like me then that has to be naturally fixed first.

 

That should be universal enough, all one needs to do is fill in those two values to PSS table, anyone can install VoodooMonitor and check the max and min control values from there. If two steps is not enough then one can add in as many as wanted/cpu is capable of. Please try to add in correct values for the whole PSS table and see if it makes any difference.

 

/edit

Seems to be usable for overclockers as well since max multiplier now comes from PSS, changed max control value to 0x81E and ran Geekbench, this is what I got:

 

/edit 2

Tested running at 8.5 * 400 without touching the dsdt, works great. Now running with all Eist and C-states options enabled and DropSSDT=n so now I am also loading the default PDC object that MC was worried about.

 

/edit 3

Just tested the same code on my MSI board, works great on that one too

 

/EDIT

This could be dangerous, please DO NOT USE THIS

[mitch_de]

very confusing :

Method (_PSS, 0, NotSerialized)

{

Return (Package(0x02)

{

Package (0x06) { 0, 0, 0, 0, 0x4820, 0 },

Package (0x06) { 0, 0, 0, 0, 0x616, 1 }

})

}

 

That looks to me : only 2 Pstates 6* and 8,5* FSB.

Whats the reason for only adding 2 Pstates ?

Or does OS X (with ACPI) see more than 2 Pstates ( IOREGISTRYExporer Pstates).

[mm67]

very confusing :

Method (_PSS, 0, NotSerialized)

{

Return (Package(0x02)

{

Package (0x06) { 0, 0, 0, 0, 0x4820, 0 },

Package (0x06) { 0, 0, 0, 0, 0x616, 1 }

})

}

 

That looks to me : only 2 Pstates 6* and 8,5* FSB.

Whats the reason for only adding 2 Pstates ?

Or does OS X (with ACPI) see more than 2 Pstates ( IOREGISTRYExporer Pstates).

 

As I said you can add as many states as you want, two is the minimum number of states, this works for me just as well.

				Package (0x06) { 0, 0, 0, 0, 0x4820, 0 },
			Package (0x06) { 0, 0, 0, 0, 0x81E, 1 },
			Package (0x06) { 0, 0, 0, 0, 0x471C, 2 },
			Package (0x06) { 0, 0, 0, 0, 0x71A, 3 },
			Package (0x06) { 0, 0, 0, 0, 0x4618, 4 },
			Package (0x06) { 0, 0, 0, 0, 0x616, 5 }

 

If I want to overclock let's say like 8 * 450 I just cut out the top package and that is it, I have multipliers from 6 to 8.

[xopher]

If I want to overclock let's say like 8 * 450 I just cut out the top package and that is it, I have multipliers from 6 to 8.

 

This is a great find. Nice! Working great here too, although I only get 4 multipliers, but nonetheless.

[mm67]

This is a great find. Nice! Working great here too, although I only get 4 multipliers, but nonetheless.

You also have all C-states and Eist on in bios and use DropSSDT=n ? I think we should keep to those settings just to be safe. Some people should also test if it makes any difference to fill in all values to PSS table.

[xopher]

You also have all C-states and Eist on in bios and use DropSSDT=n ? I think we should keep to those settings just to be safe. Some people should also test if it makes any difference to fill in all values to PSS table.

 

I do have all C-states and EIST enabled in BIOS, yes. I didn't specify DropSSDT=n in my boot.plist, but isn't that the default value that chameleon reads if nothing is specified? Oh, and what does DropSSDT really do, ie. what does 'Skip the SSDT tables while relocating the ACPI tables.' really mean?

 

Edit: By the way, my HD-videos stutter a bit sometimes. Apparently because of p/c-states changing. MC wrote something about not letting CPU0 enter C2, C3, C4 modes. Have you confirmed this? Thanks.

[mm67]

I do have all C-states and EIST enabled in BIOS, yes. I didn't specify DropSSDT=n in my boot.plist, but isn't that the default value that chameleon reads if nothing is specified? Oh, and what does DropSSDT really do, ie. what does 'Skip the SSDT tables while relocating the ACPI tables.' really mean?

It does exactly what the name says, drop ssdt as in don't load ssdt tables. You can see what happens here:

 

Use DropSSDT=y and those tables are gone. And DropSSDT=n is default so you are okay.

 

I only have some 720p clips and I can't see any stuttering on those. You can easily check if that is caused by P-states or C-states, just comment out one or the other and see if that helps.

 

/edit

This is the same dsdt with CST setup like MC wants it, see if there is any difference. To me this one feels like everything is moving in slow motion.

dsdt_new.dsl.zip

 

/edit 2

Had a typo in it, please download again. Now this feels usable.

[xopher]

/edit

This is the same dsdt with CST setup like MC wants it, see if there is any difference. To me this feels like everything is moving in slow motion.

 

 

Hm, I'll check it out and report back.

 

Edit: Well, let's see if I get any stutter. If it's not this, then it's probably my HDD.