1905 replies to this topic

[FKA]

xopher, on Oct 18 2009, 05:30 PM, said:

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.]

FormerlyKnownAs, on Oct 18 2009, 06:58 PM, said:

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.insanelym...p...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   191.49K   51 downloads
It has the USB-problem fixed for me.

The second one:
 dsdt_hdef_lan_gfx_pwrb_UHCn_UHCI_EHCI_comments.txt   202.79K   113 downloads
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.]

xopher, on Oct 18 2009, 09:06 PM, said:

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_wor..._builtin.txt
It has the USB-problem fixed for me.

The second one:
dsdt_hde...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]

Matthew L., on Oct 18 2009, 10:28 PM, said:

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:

Quote

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   220.39K   93 downloads

[Matthew L.]

xopher, on Oct 18 2009, 09:31 PM, said:

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]

Matthew L., on Oct 18 2009, 10:56 PM, said:

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]

xopher, on Oct 18 2009, 10:38 PM, said:

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.

mm67, on Oct 18 2009, 08:37 AM, said:

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]

Master Chief, on Oct 19 2009, 01:31 AM, said:

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]

xopher, on Oct 19 2009, 01:48 AM, said:

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!

xopher, on Oct 19 2009, 01:48 AM, said:

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?

[xopher]

Master Chief, on Oct 19 2009, 03:04 AM, said:

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!


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?

1) It works without the device_type bits in _DSM.
2) Doesn't help, still doesn't work.
3) Sleep doesn't seem to work for me at the moment no. Monitor turns off, computer stops gets quiet, but not totally silent, so it's not turned off completely. Oh, and doesn't wake from mouse/kb/PWRB.
4) Restart/shutdown without OpenHaltRestart.kext <- have to check this one out, brb.

I've attached my current DSDT for your viewing pleasure.

Attached Files

•  DSDT_removed_device_type.txt   201.71K   47 downloads

[Master Chief]

xopher, on Oct 19 2009, 02:45 AM, said:

1) It works without the device_type bits in _DSM.

Just what I expected.  Great news!

xopher, on Oct 19 2009, 02:45 AM, said:

2) Doesn't help, still doesn't work.

I see. Thanks for testing.

xopher, on Oct 19 2009, 02:45 AM, said:

3) Sleep doesn't seem to work for me at the moment no. Monitor turns off, computer stops gets quiet, but not totally silent, so it's not turned off completely. Oh, and doesn't wake from mouse/kb/PWRB.

That might actually be due to a bit not being high.  Please try this:

		Method (_L0D, 0, NotSerialized)
		{
			Store (0x01, \_SB.PCI0.EHCI.PMES) // Port Wake Implemented
			Notify (\_SB.PCI0.EHCI, 0x02) // Renamed from: USBE
			Notify (\_SB.PWRB, 0x02)

			Store (0x01, \_SB.PCI0.UHCI.PMES) // Port Wake Implemented
			Notify (\_SB.PCI0.UHCI, 0x02) // Renamed from: USE2
			Notify (\_SB.PWRB, 0x02)

			Notify (\_SB.PCI0.HDEF, 0x02)
			Notify (\_SB.PCI0.IGBE, 0x02)
		}

Oh, and do you really need the _DSM Method in the UHCn (former USBn) devices?  If not, remove them.

[keeza]

mm67, on Oct 18 2009, 05:18 AM, said:

With these modifications I have no more problems with sleep.
usbtest2.dsl.zip

Ehci modifications make ehci ports show up as internal, otherwise they are shown as expansion slots which seems to kill
power to usb during sleep.Uhci device modifications give wake up by usb.

I can verify that the original additions to EHCI and UHCI ports made them show up as expansion slots and thus the device removal error returned on wake.

mm67's alterations makes them show as built in and thus error is fixed.

With these additions though, wake up from usb keyboard and mouse is not possible for me as they are connected to my cinema display's usb hub. It would be nice if that could be addressed at some point. Wake works fine though when connected to the mobo.

MC,

Is it possible to get Audio working for ALC889A using just dsdt and no legacy kexts?

We get various results when using different kexts, not all sound prefs are available, have tried different combo's. I am yet not aware of a perfectly working audio solution for our boards.

I'm thinking that there must be a way for audio to be fully functional via dsdt and vanilla AppleHDA.

The King posted a tutorial on audio but its still incomplete.   Link here

Sorry if I've hijacked the thread but it looks as if the USB fix has been nailed thanks to the good work here by yourself and others.

[mm67]

xopher, on Oct 19 2009, 03:45 AM, said:

1) It works without the device_type bits in _DSM.
2) Doesn't help, still doesn't work.
3) Sleep doesn't seem to work for me at the moment no. Monitor turns off, computer stops gets quiet, but not totally silent, so it's not turned off completely. Oh, and doesn't wake from mouse/kb/PWRB.
4) Restart/shutdown without OpenHaltRestart.kext <- have to check this one out, brb.

I've attached my current DSDT for your viewing pleasure.

As I said there are 6+1 UHCI devices on ICH10, your dsdt is missing the +1. If I leave that out I get exactly the same symptoms. Take a look at my dsdt, it is the device called US31. And I can confirm that the device type bits are not necessary.

[Master Chief]

mm67, on Oct 19 2009, 09:35 AM, said:

As I said there are 6+1 UHCI devices on ICH10, your dsdt is missing the +1. If I leave that out I get exactly the same symptoms. Take a look at my dsdt, it is the device called US31.

You may want to re-read the Intel datasheet again, and then please pay attention to the following section: "Port-Routing Logic" (see attachments) because the default EHCI setup is "Six and Six" where the extra port, configured at BIOS post, is only used in the "Eight and Four" setup.   You must have missed this text: "D26:F2 can be configured as D29:F3 during BIOS Post."  

In short: You can remove that port from your DSDT when in the "Six and Six" configuration, which is again the default setup.  Do you perhaps have some kind of BIOS setting for this?

mm67, on Oct 19 2009, 09:35 AM, said:

And I can confirm that the device type bits are not necessary.

Thank you for this confirmation.  I sort of knew this already, but I like you people to confirm it for me.

keeza, on Oct 19 2009, 06:38 AM, said:

I can verify that the original additions to EHCI and UHCI ports made them show up as expansion slots and thus the device removal error returned on wake.

EHCI only.  UHCI is fine.

keeza, on Oct 19 2009, 06:38 AM, said:

With these additions though, wake up from usb keyboard and mouse is not possible for me as they are connected to my cinema display's usb hub. It would be nice if that could be addressed at some point. Wake works fine though when connected to the mobo.

Which to me basically means that we are not done, yet.  And audio fixes will have to wait for now, or things will get out of control rapidly.

Attached Files

•  Port_Routing_Logic.png   54.82K   382 downloads

[William Parker]

@ Master Chief
I need help regarding how to enter 0xfe into keyboard controller (port 64) if that will help get rid of OpenHaltRestart.
Really appreciate your good work here.
Thank you very much

[iSoprano]

mm67, on Oct 19 2009, 08:35 AM, said:

As I said there are 6+1 UHCI devices on ICH10, your dsdt is missing the +1. If I leave that out I get exactly the same symptoms. Take a look at my dsdt, it is the device called US31. And I can confirm that the device type bits are not necessary.

usbtest.dsl.zip

Eureka, I've sleep...and most important of all, my rig runs around 40c with vanilla speedstepping. @mm67, can you check your temperature and do the AppleLPC trick, which is to add one of Apple's default device ID into DSDT. This makes CST info appear in IO register. AFter that do check your temperature again.

For me, atleast, I either used to get low temp speedstep with out sleep or high temp speedstep with sleep.
Obviously, this thread helped me in getting low temp with sleep.

Many thanks to Master Chief and all the people who contributed.

@Master Chief, looking forward to having vanilla restart and shutdown without any OpenHaltRestart kext. I have shutdown without the kext but restart isn't working     without the kext

attachment removed...please see first post for attachment

[xopher]

mm67, on Oct 19 2009, 10:35 AM, said:

As I said there are 6+1 UHCI devices on ICH10, your dsdt is missing the +1. If I leave that out I get exactly the same symptoms. Take a look at my dsdt, it is the device called US31. And I can confirm that the device type bits are not necessary.

usbtest.dsl.zip

I added the Device (US31), but no effect. I wasn't actually running the AppleCPUPM.kext earlier, for some reason, and I had forgot to edit HPET, so when I booted with -f, I got a KP. That's fixed now, I have working p-states again, not just min and max. Sleep also works, but wakeup by mouse/keyboard doesn't yet. Oh, and my temperatures are back to the non-disabler-normal. Ie 8-10c higher than before.

Is there a fix for this already?  

@ MasterChief, I actually noticed this after I was trying to restart without the OpenHalt-kext, it didn't get unloaded at all first. So thanks ;-) Haven't tried it now that I got everything running again, I'll do that now and report back to you in a bit. Edit: Doesn't work w/o OpenHaltRestart.kext

I've attached my latest DSDT as for now, sans the US31.

Attached Files

•  DSDT_rc5.txt   201.17K   47 downloads

[mm67]

Master Chief, on Oct 19 2009, 02:41 PM, said:

You may want to re-read the Intel datasheet again, and then please pay attention to the following section: "Port-Routing Logic" (see attachments) because the default EHCI setup is "Six and Six" where the extra port, configured at BIOS port, is only used in the "Eight and Four" setup.   You must have missed this text: "D26:F2 can be configured as D29:F3 during BIOS Post."  

In short: You can remove that port from your DSDT when in the "Six and Six" configuration, which is again the default setup.  Do you perhaps have some kind of BIOS setting for this?

You are right, I have no idea where that US31 came from, must have done a copy/paste from someone's dsdt since I don't have that device in my original acpidumps. It was using the address of UHC4 so everything looked like it was working.
Here is a version with correct addresses.
 usbtest.dsl.zip   11.4K   60 downloads

[xopher]

mm67, on Oct 19 2009, 03:25 PM, said:

Your right, I have no idea where that US31 came from, must have done a copy/paste from someone's dsdt since I don't have that device in my original acpidumps. It was using the address of UHC4 so everything looked like it was working.
Here is a version with correct addresses.
usbtest.dsl.zip

I think you forgot to remove "Notify (\_SB.PWRB, 0x02)", on line 593. Just comparing differences, and it caught my eye.


On a second note:

Added a fix to make SATA drives be recognized as built-in, which allows you to remove IOACHIBlockStorageInjector.kext.

TIP: Search for "Device (PRIM)" and then scroll up just a bit. You should see the code "FAS0, FAS1" etc. just above that. Right after the closing curly brace, copy and paste in the code in bold:

		  FAS0,   2, 
					FAS1,   2
				}

[b]				Method (_DSM, 4, NotSerialized)
				{
					Store (Package (0x02)
						{
							"device-id", 
							Buffer (0x04)
							{
								0x81, 0x26, 0x00, 0x00
							}
						}, Local0)
					DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					Return (Local0)
				}[/b]

				Device (PRIM)
				{
					Name (_ADR, Zero)
					Method (_GTM, 0, NotSerialized)

Source: http://efixusers.com...478&postcount=6

There are two Device (PRIM)'s in my DSDT, one for IDE1 and one for IDE2, I added the code to both of them, even though it works just fine when added to just IDE1, thought on this?

Hey, and it works! :-)