Jump to content

DSDT fixes for Gigabyte boards


iSoprano
 Share

1,909 posts in this topic

Recommended Posts

For OS to know that the package is declares C4 C-State you must set Type to 0x04

 

Yes, if you follow acpispec strictly that value should be defined as 4. However the cpu will go to C4 state because of that 416 register.

Link to comment
Share on other sites

No, that register 416 is PMBASE+16h (LV4), reading of that register puts CPU in C4 state. Page 469 of ICH10 datasheet.

If I use 415 instead then CPU will go to C3 state.

 

 

 

 

Yes, it will work for you. Original Gigabyte C1 definition defines C1, fixed one defines C1E state. There is no point to define C1 since every CPU starting from 486 supports that state anyway, I think that is why OS X doesn't accept it.

 

I ask that because I thought these values were board specific. I have an EP45-UD3L.

Link to comment
Share on other sites

Yes, if you follow acpispec strictly that value should be defined as 4. However the cpu will go to C4 state because of that 416 register.

You are right. We discussed about correct CState( Type) values only.

 

Bonus :) :

Original values for my Benq R56:

 

Return (Package (0x04)
{
0x03, 
Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0x0000, 0x01,)}, 0x01, 0x01, 0x03E8}, // C1
Package (0x04) {ResourceTemplate () {Register (SystemIO, 0x08, 0x00, 0x1014, ,)}, 0x02, 0x01, 0x01F4}, // C2
Package (0x04) {ResourceTemplate () {Register (SystemIO, 0x08, 0x00, 0x1016, ,)}, 0x03, 0x39, 0x64} // C4
})

Link to comment
Share on other sites

You are right. We discussed about correct CState( Type) values only.

 

Bonus :D :

Original values for my Benq R56:

 

					Return (Package (0x04)
				{
					0x03, 
					Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0x0000, 0x01,)}, 0x01, 0x01, 0x03E8}, // C1
					Package (0x04) {ResourceTemplate () {Register (SystemIO, 0x08, 0x00, 0x1014, ,)}, 0x02, 0x01, 0x01F4}, // C2
					Package (0x04) {ResourceTemplate () {Register (SystemIO, 0x08, 0x00, 0x1016, ,)}, 0x03, 0x39, 0x64} // C4
				})

 

It is more clear if you use correct values for C-states, most manufacturers just don't seem to do it like that. Macpro4,1 SSDT however has clearly marked C-states, like this for example:

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

               0x01, 
               0x01, 
               0x03E8
           }, 

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

               0x03, 
               0x11, 
               0x01F4
           }, 

           Package (0x04)
           {
               ResourceTemplate ()
               {
                   Register (FFixedHW, 
                       0x01,               // Bit Width
                       0x02,               // Bit Offset
                       0x0000000000000020, // Address
                       0x03,               // Access Size
                       )
               }, 

               0x06, 
               0x11, 
               0x015E
           }, 

           Package (0x04)
           {
               ResourceTemplate ()
               {
                   Register (FFixedHW, 
                       0x01,               // Bit Width
                       0x02,               // Bit Offset
                       0x0000000000000030, // Address
                       0x03,               // Access Size
                       )
               }, 

               0x07, 
               0x11, 
               0xC8
           }

Link to comment
Share on other sites

I can see 3 different sets of values for CST, returned according to a certain CFGD value (0x80, 0x40 or 0x20).

Which should I put in my DSDT?

 

The CFGD package you should use depends on your BIOS settings - you can read about it below.

See post 5

Link to comment
Share on other sites

The CFGD package you should use depends on your BIOS settings - you can read about it below.

See post 5

 

What is the result if you run this: sudo setpci -s 0:1f.0 0xa0.w

 

On my board it is 06a0, so bit 7 is set. And the meaning of that bit is this (from ICH10 datasheet) :

 

Enter C4 When C3 Invoked (C4onC3_EN) — R/W. If this bit is set, then when software does a LVL3 read, the ICH10 transitions to the C4 state

 

So if you use a CST package which uses register 0x415, like the one under CFGD 0x40 option, you will still end up to C4 instead of C3 but with wrong latency value.

Link to comment
Share on other sites

What is the result if you run this: sudo setpci -s 0:1f.0 0xa0.w

 

On my board it is 06a0, so bit 7 is set. And the meaning of that bit is this (from ICH10 datasheet) :

 

Enter C4 When C3 Invoked (C4onC3_EN) �€” R/W. If this bit is set, then when software does a LVL3 read, the ICH10 transitions to the C4 state

 

So if you use a CST package which uses register 0x415, like the one under CFGD 0x40 option, you will still end up to C4 instead of C3 but with wrong latency value.

So it's completely possible the speedstepping could prevent C3 sleep (auto-sleep)? Still trying to figure out the auto-sleep thing.
Link to comment
Share on other sites

So it's completely possible the speedstepping could prevent C3 sleep (auto-sleep)? Still trying to figure out the auto-sleep thing.

 

I am talking about C3 state, you are talking about S3, two different things.

Link to comment
Share on other sites

I am talking about C3 state, you are talking about S3, two different things.
But the processor must enter C3 (processor sleep) in order for the system to enter S3 (system sleep) right? So there is a direct relation/dependency there.
Link to comment
Share on other sites

What is the result if you run this: sudo setpci -s 0:1f.0 0xa0.w

 

On my board it is 06a0, so bit 7 is set. And the meaning of that bit is this (from ICH10 datasheet) :

 

Enter C4 When C3 Invoked (C4onC3_EN) �€” R/W. If this bit is set, then when software does a LVL3 read, the ICH10 transitions to the C4 state

 

So if you use a CST package which uses register 0x415, like the one under CFGD 0x40 option, you will still end up to C4 instead of C3 but with wrong latency value.

 

I get the same 06a0.

 

Interesting though, I tried using IO address of 416 and 0x03 0x96 0x64 and I lost CST info.

 

What I would like to know is what does the number under cstinfo represent? Now I have 1240105 which I think most people have whereas before I had this value?

 

EDIT:

I do get cstinfo using the above values - 1240105

Link to comment
Share on other sites

But the processor must enter C3 (processor sleep) in order for the system to enter S3 (system sleep) right? So there is a direct relation/dependency there.

 

I don't think so, how would sleep then work for those people that have only C1 or C1 & C2. Or for me that have C1, C2 and C4.

 

 

 

 

I get the same 06a0.

 

Interesting though, I tried using IO address of 416 and 0x03 0x96 0x64 and I lost CST info.

 

What I would like to know is what does the number under cstinfo represent? Now I have 1240105 which I think most people have whereas before I had this value?

 

Really ? For me it doesn't matter if I use 415 or 416, even this works:

	Method (CST, 0, NotSerialized)
{
	Return (Package (0x5)
	{
		0x4, 
		Package (0x4){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x000,,)},0x1,0x01,0x3E8}, 
		Package (0x4){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x414,,)},0x2,0x01,0x1F4}, 
		Package (0x4){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x415,,)},0x3,0x55,0x0FA}, 
		Package (0x4){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x416,,)},0x4,0x96,0x064}, 
	})
}

Link to comment
Share on other sites

I don't think so, how would sleep then work for those people that have only C1 or C1 & C2. Or for me that have C1, C2 and C4.
Well for me I wasn't able to extract any c-states. After reading the tech doc it seems my processor only supports C1E so I shouldn't be using the other two in my DSDT. I assumed it was a bug in the Gigabyte board.

 

I should use this:

        Name (CST, Package (0x04) {
           0x01,
           Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8}
       })

 

…instead of this:

        Name (CST, Package (0x04) {
           0x03,
           Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000414,    ,)},0x02,One,0x01F4}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000415,    ,)},0x03,0x55,0xFA}
       })

 

And I'm thinking maybe this might be the problem.

 

Also the tech docs says your processor supports C1, C3 and C4.

Link to comment
Share on other sites

Well for me I wasn't able to extract any c-states. After reading the tech doc it seems my processor only supports C1E so I shouldn't be using the other two in my DSDT. I assumed it was a bug in the Gigabyte board.

 

I should use this:

        Name (CST, Package (0x04) {
           0x01,
           Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8}
       })

 

…instead of this:

        Name (CST, Package (0x04) {
           0x03,
           Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000414,    ,)},0x02,One,0x01F4}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000415,    ,)},0x03,0x55,0xFA}
       })

 

And I'm thinking maybe this might be the problem.

 

Also the tech docs says your processor supports C1, C3 and C4.

 

If your bios doesn't show C2 and C4 options then you probably have an older version of Quad core cpu, those do support only C1E. That could be your problem.

Link to comment
Share on other sites

Re: the cstate info can anyone verify the ioreg from a macpro3,1 - cstinfo value?

 

I found this on the net, what is the relevance of this number I wonder...

 

That value changed with 10.6.2 kernel, at least iMac10,1 and iMac11,1 ioreg dumps have that new 0x1240105 value

Link to comment
Share on other sites

I get the same 06a0.

 

Interesting though, I tried using IO address of 416 and 0x03 0x96 0x64 and I lost CST info.

 

What I would like to know is what does the number under cstinfo represent? Now I have 1240105 which I think most people have whereas before I had this value?

 

EDIT:

I do get cstinfo using the above values - 1240105

 

 

I have an EX58-UD5 (ICH10R) with bios f9m

 

My idle (auto) sleep has always been regular as clockwork

 

I get

 

sudo setpci -s 0:1f.0 0xa0.w

Password:

06e0

 

Currently I have ..., but I also get the same result with 0x16 , 0x3A (ICH10R)

 

          
           Device (LPCB)
           {
               Name (_ADR, 0x001F0000)
               Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x02)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x18, 0x3A, 0x00, 0x00
                           }
                       }, Local0)
                   DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                   Return (Local0)
               }

               OperationRegion (PREV, PCI_Config, 0x08, One)
               Scope (\)
               {
                   Field (\_SB.PCI0.LPCB.PREV, ByteAcc, NoLock, Preserve)
                   {
                       REV0,   8
                   }
               }

 

and AppleLPC runs on both occasions

 

AppleLPC:

 Version:	1.4.9
 Last Modified:	01/08/2009 06:57
 Kind:	Intel
 Architectures:	i386, x86_64
 64-Bit (Intel):	Yes
 Location:	/System/Library/Extensions/AppleLPC.kext
 Kext Version:	1.4.9
 Load Address:	0xffffff7f80916000
 Valid:	Yes
 Authentic:	Yes
 Dependencies:	Satisfied

Link to comment
Share on other sites

Hi fellows, i´ve tried to use the Chameleon2 RC4 + Rekursor´s system ID patch + Duvel300´s v2.1 RestartFix, that BlackOSX have compiled. But it didn´t works for me..

Talking to BlackOSX, I noted that he forgot to update some files needed to work of the PCiRoot patch (by Rekursor - pci_root.c, pci_root.o, Makefile ...)

So, i recompiled the Chameleon2 RC4 sources with Duvel300's v2.1 Restart Fix with Rekursor's SystemID and PCIRoot patches.

 

Now, either RestartFix and SystemID/PCIRoot patches works correctly..

Thanks Blackosx for idea.

 

Regards for all.

Thiago.

 

 

Hmmm...

 

I am trying to use this on my new p55 build, and for some reason the Restart part is not working. If I just use Duvel300's patched boot file, it works great. But, when using this one, the display blanks, and it just sits there with the fans spinning etc.

 

I need Rekursor's SystemID patch to work so that I can reinstall iTunes and other apps...

 

Anyone else having issues with this compile and the restart?

Link to comment
Share on other sites

Hmmm...

 

I am trying to use this on my new p55 build, and for some reason the Restart part is not working. If I just use Duvel300's patched boot file, it works great. But, when using this one, the display blanks, and it just sits there with the fans spinning etc.

 

I need Rekursor's SystemID patch to work so that I can reinstall iTunes and other apps...

 

Anyone else having issues with this compile and the restart?

 

 

Worked for me, I did set my pci root = 1 though (which it is for my board)

 

<key>PciRoot</key>
<string>1</string>

 

everything seems to work including restart although I get a new random SystemID generated regardless

of what I want to set it to

Link to comment
Share on other sites

Hmmm...

 

I am trying to use this on my new p55 build, and for some reason the Restart part is not working. If I just use Duvel300's patched boot file, it works great. But, when using this one, the display blanks, and it just sits there with the fans spinning etc.

 

I need Rekursor's SystemID patch to work so that I can reinstall iTunes and other apps...

 

Anyone else having issues with this compile and the restart?

 

Dump your FACP tables using both boot files and check if you see any differences. On my MSI reset register and register value are already set without patching, only Reset register supported has value 0 without the patch.

Link to comment
Share on other sites

Well for me I wasn't able to extract any c-states. After reading the tech doc it seems my processor only supports C1E so I shouldn't be using the other two in my DSDT. I assumed it was a bug in the Gigabyte board.

 

I should use this:

        Name (CST, Package (0x04) {
           0x01,
           Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8}
       })

 

…instead of this:

        Name (CST, Package (0x04) {
           0x03,
           Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000414,    ,)},0x02,One,0x01F4}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000415,    ,)},0x03,0x55,0xFA}
       })

 

And I'm thinking maybe this might be the problem.

 

Also the tech docs says your processor supports C1, C3 and C4.

 

I've been through this exercise 2 weeks ago when I realized my CPU only supported C1E. I use the following for C-states:

 

Name (CST, Package (0x02) {
               0x01,
               Package (0x04) {ResourceTemplate () {Register (FFixedHW, 1, 2, 0x000, 0x01,)},1,0x01,0x0384} 
       }) 

 

0x0384 is a value for our mobo based on an FACP table dump.

 

[05Fh 0095 1] _CST Support : 00

[060h 0096 2] C2 Latency : 005A

[062h 0098 2] C3 Latency : 0384

 

Where does 03E8 in yours come from? I understood that while the CPU may support certain C-states, the motherboard values are what populates the DSDT based on this FACP table. No matter the value here or the c-state code in the DSDT, my auto sleep still doesn't work. Here are a few shots of my BIOS settings if it helps to shed any light.

 

post-422466-1262285022_thumb.jpg post-422466-1262285034_thumb.jpg

post-422466-1262285043_thumb.jpg post-422466-1262285780_thumb.jpg post-422466-1262285792_thumb.jpg

Link to comment
Share on other sites

I've been through this exercise 2 weeks ago when I realized my CPU only supported C1E. I use the following for C-states...
At this point I don't remember where that value came from but I believe it's from the MacPro. I'll have to go back and look at it again.

 

However I did get auto-sleep to work again but I had to do a complete reinstall. So I have two installations my old one and the new one. They both use the exact same BIOS settings, bootloader and Extra Folder contents so they're fundamentally the same. The only difference is I haven't customized my new install. I still need to install CS4 as well as a couple dozen other smaller apps. I'm guessing it's one of those apps that's causing all the trouble.

 

Good luck to me trying to pin it down!

Link to comment
Share on other sites

 Share

×
×
  • Create New...