DSDT fixes for Gigabyte boards

[mm67]

Great. Nice work.

 

 

That's a good start. I however fail to see any logic in using the wrong device name, and then having to set device_type to "EHCI". Yes, you might need to change the device_id but that's about it.

 

According to Intel ICH10 datasheet I have 6+1 Uhci devices and 2 Ehci devices, don't know about ICH9.

 

The reason is pretty obvious; the PSS object data in the BIOS is usually way overpowered. Giving it less juice makes it life longer. I'll let people decide what they want to use, but I think to know the answer already.

 

That is right, handmade PSS table works a little bit cooler, but then again that is not universal.

[yeehaa]

I don't see the point in running 2 DSDT speedstepping threads.

 

Post moved: http://www.insanelymac.com/forum/index.php...p;#entry1301888

 

D.

 

but the other thread is for Cstates, right?

and this one all things gigabyte.

[keeza]

Just a quick question,

 

The USB fix metioned at the outset of this thread adds info to the USB devices and to the EHCI device.

 

I had read previously that EP45 boards only require EHCI devices to be fixed whereas EP35 boards require the method added to the USB devices.

 

Presently, sleep works fine (manual) and usb device removal error has been fixed. Only thing that I've noticed is that my mouse doesn't wake my computer from sleep when connected to my cinema display's usb hub. When connected to the motherboard it wakes fine.

 

Should I fix it if it ain't broke or am I missing something?

 

Attached is my current dsdt.

dsdt.dsl.zip

[Master Chief]

where do I start - i can whinge for england!

seriously - nothing here!

"DSDT fixes for Gigabyte boards" does it for me

 

dude - a lot of people have put a lot of FREE work into this forum.

Your work is very much appreciated (as is everybody elses) and is very fresh.

 

Don't burn yourself out over it!

Trust me I won't. And that is why I want a little control over things

[mm67]

Just a quick question,

 

The USB fix metioned at the outset of this thread adds info to the USB devices and to the EHCI device.

 

I had read previously that EP45 boards only require EHCI devices to be fixed whereas EP35 boards require the method added to the USB devices.

 

Presently, sleep works fine (manual) and usb device removal error has been fixed. Only thing that I've noticed is that my mouse doesn't wake my computer from sleep when connected to my cinema display's usb hub. When connected to the motherboard it wakes fine.

 

Should I fix it if it ain't broke or am I missing something?

 

Attached is my current dsdt.

 

I don't see any new functionality with this usb fix, both work just the same for me.

[FKA]

Just a quick question,

 

The USB fix metioned at the outset of this thread adds info to the USB devices and to the EHCI device.

 

I had read previously that EP45 boards only require EHCI devices to be fixed whereas EP35 boards require the method added to the USB devices.

 

Presently, sleep works fine (manual) and usb device removal error has been fixed. Only thing that I've noticed is that my mouse doesn't wake my computer from sleep when connected to my cinema display's usb hub. When connected to the motherboard it wakes fine.

 

Should I fix it if it ain't broke or am I missing something?

 

Attached is my current dsdt.

 

with ICH9 (P35) I've had to give my USB devices the device id for ICH10 (P45)

you should only need to add/ edit the EHCI part so they are shown as internal in system profiler - as apposed to 'expansion slot'

 

D.

[Master Chief]

According to Intel ICH10 datasheet I have 6+1 Uhci devices and 2 Ehci devices, don't know about ICH9.

But of course. The ICH9 has also two EHCI controllers, but in a MacPro3,1 one is named UHCI That's why I use this name, because one of my goals is to get my DSDT as close as possible to a MacPro3,1

 

That is right, handmade PSS table works a little bit cooler, but then again that is not universal.

Unfortunately not no, but then again almost nothing is (take a look at P35/P45 boards for example).

 

I don't see any new functionality with this usb fix, both work just the same for me.

But then again... nobody here said anything about adding feature/functionality.

 

Just a quick question,

 

The USB fix metioned at the outset of this thread adds info to the USB devices and to the EHCI device.

 

I had read previously that EP45 boards only require EHCI devices to be fixed whereas EP35 boards require the method added to the USB devices.

 

Presently, sleep works fine (manual) and usb device removal error has been fixed. Only thing that I've noticed is that my mouse doesn't wake my computer from sleep when connected to my cinema display's usb hub. When connected to the motherboard it wakes fine.

 

Should I fix it if it ain't broke or am I missing something?

 

Attached is my current dsdt.

Try it and be surprised – I have my mouse receiver connected to the hub and wakeup works with the mouse.

[mm67]

But of course. The ICH9 has also two EHCI controllers, but in a MacPro3,1 one is named UHCI That's why I use this name, because one of my goals is to get my DSDT as close as possible to a MacPro3,1

 

 

Unfortunately not no, but then again almost nothing is (take a look at P35/P45 boards for example).

 

 

But then again... nobody here said anything about adding feature/functionality.

 

 

Try it and be surprised – I have my mouse receiver connected to the hub and wakeup works with the mouse.

 

Ok, now I understand more about Your goals.

Care to explain how this works, Your cst has C1 like this:

 

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

 

and Gigabyte vanilla cst has it like this:

                        ResourceTemplate ()
                       {
                           Register (FFixedHW, 
                               0x00,               // Bit Width
                               0x00,               // Bit Offset
                               0x0000000000000000, // Address
                               ,)
                       }, 

                       0x01, 
                       0x01, 
                       0x03E8

 

That bit width and bit offset are the only thing that prevents me from loading vanilla cst tables. How and where are these checked ? And is there anyway to make this check ignore Gigabytes badly written cst.

[Master Chief]

Ok, now I understand more about Your goals. Care to explain how this works, Your cst has C1 like this:...

I've read Your post twice now, and can't stop thinking about the funny way of writing You and Your in the middle of a line. Just weird. Don't You agree?

 

But seriously now; your SSDT includes four IST and four CST tables. Why don't you use these, instead of trying to add other peoples stuff? Maybe it is just me failing to see the logic here, but then again maybe you can help me understand it by attaching your ACPIdump and all tables.. including the original DSDT. Thanks.

 

p.s. Sorry, but I cannot answer your question (confidential information from Intel).

[mm67]

I've read Your post twice now, and can't stop thinking about the funny way of writing You and Your in the middle of a line. Just weird. Don't You agree?

 

But seriously now; your SSDT includes four IST and four CST tables. Why don't you use these, instead of trying to add other peoples stuff? Maybe it is just me failing to see the logic here, but then again maybe you can help me understand it by attaching your ACPIdump and all tables.. including the original DSDT. Thanks.

 

p.s. Sorry, but I cannot answer your question (confidential information from Intel).

 

English is not my native language...Let's see how you write finnish But anyway here is my original acpidump.

ACPI_Tables.zip

 

I am using original ist tables but Gigabyte cst tables are buggy. What I want to know is if

there is some way to ignore this, like Linux and Windows seem to do.

[Master Chief]

English is not my native language...Let's see how you write finnish But anyway here is my original acpidump.

ACPI_Tables.zip

That would be something eh: Kiitos kohteliaisuus mutta koska en ole englanti

 

I am using original ist tables but Gigabyte cst tables are buggy.

How come? What is the problem?

 

What I want to know is if there is some way to ignore this, like Linux and Windows seem to do.

 

Use 0x40383E2 instead of 0x40383F2 for CFGD which invalidates If (And (CFGD, 0x10)) and thus the tables won't load. Or use a customized SSDT object in your DSDT.

[mm67]

That would be something eh: Kiitos kohteliaisuus mutta koska en ole englanti

 

 

How come? What is the problem?

 

 

 

Use 0x40383E2 instead of 0x40383F2 for CFGD which invalidates If (And (CFGD, 0x10)) and thus the tables won't load. Or use a customized SSDT object in your DSDT.

 

That's just what I do now, I mean i have removed the lines to load original cst tables and use customized object instead. What I want to do is use 0x4048352 and load the vanilla cst tables. Now that is impossible because of those two lines in Gigabytes cst.

 

Yes, that is some finnish words in a very strange order

[milanca]

@iSoprano,

 

for testing, will you remove your gfx part from your dsdt and boot SL in vesa mode. If USBs are fixed and the system goes to sleep and wakes up, it seems that broken sleep is caused by gfx.

[iSoprano]

@iSoprano,

 

for testing, will you remove your gfx part from your dsdt and boot SL in vesa mode. If USBs are fixed and the system goes to sleep and wakes up, it seems that broken sleep is caused by gfx.

 

Sleep doesn't work for me when I use MacPro3,1 CST tables. The monitor switches off but the cpu fan keeps spinning..... The trade off is CPU runs around 35-40C. If I don't use MP3,1 tables then I get sleep back but cpu runs 10C hotter around 50C.

 

I hope someone could give me solution for fixing my CPU fan....so that I could keep the MP3,1 tables

[xopher]

Sleep doesn't work for me when I use MacPro3,1 CST tables. The monitor switches off but the cpu fan keeps spinning..... The trade off is CPU runs around 35-40C. If I don't use MP3,1 tables then I get sleep back but cpu runs 10C hotter around 50C.

 

I hope someone could give me solution for fixing my CPU fan....so that I could keep the MP3,1 tables

 

The DS4 doesn't give you cst-tables while dumping DSDT? I got the ud3r, and I get cst-tables.. But only if I run ACPI-dump in linux. Haven't tried Everest in Windows yet, but that'll probably have the same outcome. (I don't have a windows livecd around..)

[FKA]

The DS4 doesn't give you cst-tables while dumping DSDT? I got the ud3r, and I get cst-tables.. But only if I run ACPI-dump in linux. Haven't tried Everest in Windows yet, but that'll probably have the same outcome. (I don't have a windows livecd around..)

 

a lot of GiGaByte MB dont have cst tables - mine included !!

 

##EDIT##

I'm yet to find somebody who does not have native cst tables in thier SSDT make c-states work !!!

 

watching this space

[Matthew L.]

a lot of GiGaByte MB dont have cst tables - mine included !!

 

##EDIT##

I'm yet to find somebody who does not have native cst tables in thier SSDT make c-states work !!!

 

watching this space

Everyone with the same problem, check here, and read the forum:

http://www.insanelymac.com/forum/index.php...t&p=1302320

 

Thanks to Master Chief, all thanks and respect goes to him!

[xopher]

I'm having trouble getting my High-speed USB-ports to show as 'Built-in' instead of 'Expansion Slot'.

 

I've followed the usb-fix on the fron page, nice work by the way, but no.

 

Here's two DSDT's, the first one:

dsdt_working_builtin.txt

It has the USB-problem fixed for me.

 

The second one:

dsdt_hdef_lan_gfx_pwrb_UHCn_UHCI_EHCI_comments.txt

Built from scratch using the information available in this thread for the USBE, USE2-fix. It reports the high-speed ports as 'Expansion slots'.

 

I'd appreciate if someone could take a peek, and perhaps tell me what I've screwed up.

 

Thanks

[Matthew L.]

I'm having trouble getting my High-speed USB-ports to show as 'Built-in' instead of 'Expansion Slot'.

 

I've followed the usb-fix on the fron page, nice work by the way, but no.

 

Here's two DSDT's, the first one:

dsdt_working_builtin.txt

It has the USB-problem fixed for me.

 

The second one:

dsdt_hdef_lan_gfx_pwrb_UHCn_UHCI_EHCI_comments.txt

Built from scratch using the information available in this thread for the USBE, USE2-fix. It reports the high-speed ports as 'Expansion slots'.

 

I'd appreciate if someone could take a peek, and perhaps tell me what I've screwed up.

 

Thanks

 

I've compared your second DSDT to this guide, and I've found that you've used the same fake device-id at all of your USB devices. You should use a different one everywhere corresponding to the device's address by the guide mentioned above.

[xopher]

I've compared your second DSDT to this guide, and I've found that you've used the same fake device-id at all of your USB devices. You should use a different one everywhere corresponding to the device's address by the guide mentioned above.

 

Thanks, I must have missed those! Cheers!

 

Update:

Ok, I added the device-ids, still the same problem. And I'm getting this error at boot because of it:

 

USBF: 1. 14 AppleUSBOHCI[0xffffff80098a7000]::CheckSleepCapability - controller will be unloaded across sleep

USBF: 1. 15 AppleUSBOHCI[0xffffff8009ac7000]::CheckSleepCapability - controller will be unloaded across sleep

 

This is my edited DSDT, with comments on top - tried to include everything I've added, I might have forgot something:

 

dsdt_incl_comments.txt

 

[Matthew L.]

Thanks, I must have missed those! Cheers!

 

Update:

Ok, I added the device-ids, still the same problem. And I'm getting this error at boot because of it:

 

 

 

This is my edited DSDT, with comments on top - tried to include everything I've added, I might have forgot something:

 

dsdt_incl_comments.txt

 

 

Can it be the source of problem that you use a buffer of just 2 (instead of 4)?

[xopher]

Can it be the source of problem that you use a buffer of just 2 (instead of 4)?

 

What buffer are you referring to? The reason I'm this perplexed, is that it works fine in the first DSDT, in my previous post - and I can't figure out what makes it tick so to speak. :/

 

Edit: I changed the buffer to 4, rebooting, and reporting back in a bit.

 

Update: Ok, booted up, still the same problem. Ideas? I don't think it has to do with the UHC1-6 devices, rather with the EHCI and UHCI devices.

[Master Chief]

What buffer are you referring to? The reason I'm this perplexed, is that it works fine in the first DSDT, in my previous post - and I can't figure out what makes it tick so to speak. :/

 

Edit: I changed the buffer to 4, rebooting, and reporting back in a bit.

 

Update: Ok, booted up, still the same problem. Ideas? I don't think it has to do with the UHC1-6 devices, rather with the EHCI and UHCI devices.

Go back to the one that worked. Rename the USBn devices to UHCn and recompile the DSDT to check everything. Then fix the UHCn devices, without changing the EHCI/UHCI devices! Recompile and check everything first, before you continue.

 

Only add the new lines to EHCI/UHCI when everything is fine. Then recompile/check everything, and see what you can change in Method _DSM. What exactly makes it fail (report as Expansion Slot).

 

p.s. the 2 versus the 4 in the DSDT might be related to the CMOS reset bug.

 

That's just what I do now, I mean i have removed the lines to load original cst tables and use customized object instead. What I want to do is use 0x4048352 and load the vanilla cst tables. Now that is impossible because of those two lines in Gigabytes cst.

But again, what exactly in the original CST is buggy? What makes you think that it is buggy?

[xopher]

Go back to the one that worked. Rename the USBn devices to UHCn and recompile the DSDT to check everything. Then fix the UHCn devices, without changing the EHCI/UHCI devices! Recompile and check everything first, before you continue.

 

Ok, the EHCI/UHCI is built-in again, I replaced this:

                Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x06)
                   {
                       "AAPL,current-available",
                       0x05DC,

                       "AAPL,current-extra",
                       0x04B0,

                       "AAPL,current-in-sleep",
                       0x09C4

                   }, Local0)

 

with this:

                Method (_DSM, 4, NotSerialized)
               {
                   Store (Package (0x06)
                       {
                           "device-id", 
                           Buffer (0x04)
                           {
                               0x3A, 0x3A, 0x00, 0x00
                           }, 

                           "AAPL,clock-id", 
                           Buffer (One)
                           {
                               0x01
                           }, 

                           "device_type", 
                           Buffer (0x05)
                           {
                               "EHCI"
                           }
                       }, Local0)

 

Under Device (EHCI), and Device (UHCI), to the latter with a slight modification, device-id 0x3C instead of 0x3A, and Buffer (One), 0x02, instead of 0x01.

 

Is doing this contradicting something you've accomplished with the ACPI-code on the first page?

 

While I'm waiting for an answer to this, I'll start cleaning up my cst, pss code. Then what?

[Master Chief]

Ok, the EHCI/UHCI is built-in again, I replaced this:

 

<snip />

 

Under Device (EHCI), and Device (UHCI), to the latter with a slight modification, device-id 0x3C instead of 0x3A, and Buffer (One), 0x02, instead of 0x01.

 

Is doing this contradicting something you've accomplished with the ACPI-code on the first page?

I first need to know a few things:

 

1) Does it work without the device_type bits in _DSM?

2) What if you only add the device_id bits and add my code?

 

Note: Don't forget to adjust Package(0x06) accordantly!

 

While I'm waiting for an answer to this, I'll start cleaning up my cst, pss code. Then what?

Let's see: Does (auto) sleep work for you? What about restart/shutdown without OpenHaltRestart.kext?

 

p.s. No attached file so I'll have to ask this: You did not add device_id's to the UHCn devices, right?