mm67 Posted October 17, 2009 Share Posted October 17, 2009 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. Link to comment Share on other sites More sharing options...
yeehaa Posted October 17, 2009 Share Posted October 17, 2009 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. Link to comment Share on other sites More sharing options...
keeza Posted October 17, 2009 Share Posted October 17, 2009 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 Link to comment Share on other sites More sharing options...
Master Chief Posted October 17, 2009 Share Posted October 17, 2009 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 Link to comment Share on other sites More sharing options...
mm67 Posted October 17, 2009 Share Posted October 17, 2009 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. Link to comment Share on other sites More sharing options...
FKA Posted October 17, 2009 Share Posted October 17, 2009 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. Link to comment Share on other sites More sharing options...
Master Chief Posted October 17, 2009 Share Posted October 17, 2009 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. Link to comment Share on other sites More sharing options...
mm67 Posted October 17, 2009 Share Posted October 17, 2009 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. Link to comment Share on other sites More sharing options...
Master Chief Posted October 18, 2009 Share Posted October 18, 2009 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). Link to comment Share on other sites More sharing options...
mm67 Posted October 18, 2009 Share Posted October 18, 2009 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. Link to comment Share on other sites More sharing options...
Master Chief Posted October 18, 2009 Share Posted October 18, 2009 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. Link to comment Share on other sites More sharing options...
mm67 Posted October 18, 2009 Share Posted October 18, 2009 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 Link to comment Share on other sites More sharing options...
milanca Posted October 18, 2009 Share Posted October 18, 2009 @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. Link to comment Share on other sites More sharing options...
iSoprano Posted October 18, 2009 Author Share Posted October 18, 2009 @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 Link to comment Share on other sites More sharing options...
xopher Posted October 18, 2009 Share Posted October 18, 2009 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..) Link to comment Share on other sites More sharing options...
FKA Posted October 18, 2009 Share Posted October 18, 2009 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 Link to comment Share on other sites More sharing options...
Matthew L. Posted October 18, 2009 Share Posted October 18, 2009 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! Link to comment Share on other sites More sharing options...
xopher Posted October 18, 2009 Share Posted October 18, 2009 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 Link to comment Share on other sites More sharing options...
Matthew L. Posted October 18, 2009 Share Posted October 18, 2009 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. Link to comment Share on other sites More sharing options...
xopher Posted October 18, 2009 Share Posted October 18, 2009 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 sleepUSBF: 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 Link to comment Share on other sites More sharing options...
Matthew L. Posted October 18, 2009 Share Posted October 18, 2009 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)? Link to comment Share on other sites More sharing options...
xopher Posted October 18, 2009 Share Posted October 18, 2009 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. Link to comment Share on other sites More sharing options...
Master Chief Posted October 18, 2009 Share Posted October 18, 2009 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? Link to comment Share on other sites More sharing options...
xopher Posted October 18, 2009 Share Posted October 18, 2009 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? Link to comment Share on other sites More sharing options...
Master Chief Posted October 19, 2009 Share Posted October 19, 2009 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? Link to comment Share on other sites More sharing options...
Recommended Posts