Jump to content

Patched AppleUSBXHCI from OS 10.8.2

Zenith432

By Zenith432,
in Other Peripheral Devices

 Share
146 posts in this topic

Recommended Posts

Zenith432
Zenith432
Posted
  • Author
Posted

So could we achieve the same using Clover's KextPatcher to edit AppleACPIPlatformExpert.kext if possible?

You can't solve this by patching AppleACPIPlatformExpert. It needs to execute the sleep/wake methods in the DSDT. That's how Apple's code is designed. The bug is in the DSDT code, but other parts of what it's doing are necessary. Windows and Linux have dedicated drivers for putting different chipsets to sleep and don't use DSDT code. That's why those OSes don't experience this problem (and also why DSDT code is so neglected...)
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

Awesome work Zenith432, have you posted the file minus the last two patches?

No, because the necessity of those patches depends on the state of the DSDT. I'll try to clarify.

PME = power management event = the process for waking the system from sleep.

In order for the xHC to have proper suspend/resume, PME must be enabled on itself and all PCI bridges in its datapath. This is because PME enabling achieves two things

  1. Allows USB devices like keyboards, mice or modems on the xHC to wake the system.
  2. Tells the system to supply aux voltage to the xHC during sleep, so it can maintain context. Without this context, the xHC must be reset after wake and all USB devices must be reenumerated.

Now, AppleUSBXHCI has two code-paths for handling sleep

  1. suspend/resume with PME enabled.
     
  2. shutdown/reset. In this mode the xHC is reset after wake, all USB devices on the xHC disconnected and reenumerated. It's what causes the popups saying that disks were disconnected.

If the xHC is listed in DSDT, AppleUSBXHCI enables PME and uses the suspend/resume method.

If the xHC is not listed in DSDT, AppleUSBXHCI uses the shutdown/reset method (without PME).

 

Now, the last patch (at 10056) forces the driver to always enable PME, even if xHC is not listed in DSDT. This is a must to have any chance of suspend/resume working. It's a correct patch, and better left in place. I reverted it myself, because I added my xHC to DSDT. Note that usually, a xHC which is not integrated into the south-bridge would not be in DSDT, (even if it's on the MB.)

 

The patch before last (10014) forces the driver to always use shutdown/reset code-path. I put it in because of the DSDT infinite-loop bug I discussed, which makes suspend/resume always fail. Once resume fails, the xHC is left in an unusable state until reboot. AppleUSBXHCI doesn't have code in it to recover from resume error by resetting the xHC and reenumerating all USB devices. It should have such code (the Linux driver does), but that's a different issue.

 

So - 10056 patch is safe and can be left in. It may not be needed, but doesn't cause harm.

 

The 10014 patch is necessary if the resume code is failing due to the DSDT bug. It's the only way to get AppleUSBXHCI to recover by xHC reset and reenumeration.

Without the DSDT bug (if it's a good DSDT, or edited and fixed), the patch at 10014 should be reverted in order to let suspend/resume work. If suspend/resume works, the xHC wakes without disconnection or reenumeration of devices, and also allows system wake by keyboards and mice.

  • Like 1
Link to comment
Share on other sites
newnekton1
newnekton1
Posted
Posted (edited)

Thanks for the very clear explanation of how this works. I now understand, but what if we have a motherboard that does not use a DSDT? If there no possible workaround? Textwalker TimeWalker seems to suggest there is a workaround in the following (below) but I don't know what he did with kextpatcher in Clover—I have PMed him and hope he reads this board soon.

Snip from TimeWalker's post above.

 

After applying the diff as a KextPatcher entry for Clover, it has successfully cured the problem and USB devices plugged into USB 3.0 ports now properly get remounted after sleep!

 

You can't solve this by patching AppleACPIPlatformExpert. It needs to execute the sleep/wake methods in the DSDT. That's how Apple's code is designed. The bug is in the DSDT code, but other parts of what it's doing are necessary. Windows and Linux have dedicated drivers for putting different chipsets to sleep and don't use DSDT code. That's why those OSes don't experience this problem (and also why DSDT code is so neglected...)

Edited by newnekton1
Link to comment
Share on other sites
TimeWalker75a
TimeWalker75a
Posted
Posted

Thanks for the very clear explanation of how this works. I now understand, but what if we have a motherboard that does not use a DSDT? If there no possible workaround? Textwalker seems to suggest there is a workaround in the following (below) but I don't know what he did with kextpatcher in Clover—I have PMed him and hope he reads this board soon.

Snip from Textwalker's post above.

 

After applying the diff as a KextPatcher entry for Clover, it has successfully cured the problem and USB devices plugged into USB 3.0 ports now properly get remounted after sleep!

firstly im not textwalker

secondly the config was posted in post #41

thirdly every motherboard uses DSDT, that's a retarded thing to say that it doesn't. it's being taken from the bios, not sideloaded as with majority of mobos out there.

Link to comment
Share on other sites
bebop68
bebop68
Posted
Posted (edited)

Thanks for the explanation Zenith432 - I'm actually using a macbook pro with expresscards so assumed it would handle all the configuration properly. I will try reverting 10014 and see if resume works. Thanks again.

 

Update:

 

I changed it from 00c6 back to 01c6 and a couple of things happened. On my asmedia 1042 card which will only work if inserted before powering up, the card showed as present but wouldn't see my usb3 drive attached to it. On my fl1000 card it would see the drive, but mount it as high speed rather than super speed much like the hacked pxhcd/mxhcd kexts, and wouldn't resume after sleep but did reset, so I got the disconnected drive complaint and it remounted the drives. Argh!

 

Update 2 - It seems to mount as super speed now.

Edited by bebop68
Link to comment
Share on other sites
newnekton1
newnekton1
Posted
Posted

My apologies TimeWalker—slip of the keyboard.

As for the retarded comment—everybody is new at this game once. I won't bother you again.

 

firstly im not textwalker

secondly the config was posted in post #41

thirdly every motherboard uses DSDT, that's a retarded thing to say that it doesn't. it's being taken from the bios, not sideloaded as with majority of mobos out there.

Link to comment
Share on other sites
shiecldk
shiecldk
Posted
Posted

its not your fault, it's mostly tony{censored}s fault for spreading false information ..

 

XD I agrees with you regarding "tony{censored}s."

 

Actually you still need to edit the DSDT of Gigabyte's UEFI MB if you want everything perfectly works.

 

One example is that you need to delete "Acquire (MUT0, 0xFFFF)" in DSDT. Otherwise you'll notice a boot delay, about three seconds, with SSD.

  • Like 1
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

newnekton1: my point was that AppleACPIPlatformExpert is not broken and doesn't need patching.

 

bebop68: Those are interesting results (with the asmedia and fl1000), which honestly - I cannot explain. According to the linux driver, there are a couple of classes of chips on which it always uses reset-on-resume - Etron xHC chip for the Asrock P67 MB, and all VIA xHC chips. I don't have the datasheet for these chips, but I assume there's a reason they added this quirk to always reset-on-resume with them. For all other xHC chips, it tries bonafide suspend/resume, and only if that fails does it reset the chip and reenumerate USB devices.

 

Apple's driver agrees to work for Intel Panther point and all FL chips, so I'm guessing those are what they tested with. The Intel chip is the only one which is integrated into the south-bridge and connected directly to the root complex. All others have at least one PCI-bridge separating them from the root-complex, and all intervening bridges must be properly configured for PME-routing in order for suspend/resume to work. Apple's software divides the configuration of PCI bridges between 1) IOPCIFamily, 2) AppleACPIPlatformExpert and 3) code executed from DSDT. So there are lots of places where things can go wrong :worried_anim:

Link to comment
Share on other sites
fau7i
fau7i
Posted
Posted
According to the linux driver, there are a couple of classes of chips on which it always uses reset-on-resume - Etron xHC chip for the Asrock P67 MB, and all VIA xHC chips.

Hi Zenith432, it's me again.

 

I would believe this as I couldn't solve the disk ejection error with Etron chip in my Z77 Extreme6 nor auto reconnection. BTW, the 1st patch enables this chip.

 

Apple's driver agrees to work for Intel Panther point and all FL chips, so I'm guessing those are what they tested with. The Intel chip is the only one which is integrated into the south-bridge and connected directly to the root complex. All others have at least one PCI-bridge separating them from the root-complex, and all intervening bridges must be properly configured for PME-routing in order for suspend/resume to work. Apple's software divides the configuration of PCI bridges between 1) IOPCIFamily, 2) AppleACPIPlatformExpert and 3) code executed from DSDT. So there are lots of places where things can go wrong :worried_anim:

Do you know why Intel chip doesn't have 2.0 backward compatibility? Yes, it works natively (Z77 Extreme6 has Intel and Etron chips) but can't detect 2.0 drives nor charge my iPhone. Looks like it stop being connected after kernelcache loaded.

 

Thanks

Link to comment
Share on other sites
rob1980
rob1980
Posted
Posted

Thanks for the time and effort put into this, what a massive improvement for me.

 

On my 4530s USB3.0 worked, but not properly. (PXHCD)

 

Unplugging a mouse no longer causes a panic, and devices like my midi controller that never worked on the USB3.0 port now work.

 

after sleep, I have the, not removed properly warning on USB drives, but it auto mounts again.

 

Many thanks!

 

Rob

Link to comment
Share on other sites
polkaholga
polkaholga
Posted
Posted

@ Zenith432

Thank you so much for your hard work on this and great explanation about how things are connected on the USB side !

Big shout out too for shiecldk for sharing his experience and links to Mieze !

I don't have any USB3 device to test speed but at least the ports are working properly and no error messages / sleep problems

anymore !

:thumbsup_anim:

Link to comment
Share on other sites
dwmc
dwmc
Posted
Posted

Thanks much for the work Zenith432! And thanks shiecldk for the clover config stuff!

 

Appears to be working on the EJ168 ports on a GA-Z68X-UDH3-B3 (both front and rear). I'm using clover to perform the patches. I don't have any USB 3.0 devices handy to plug into the hackintosh, but my iPhone syncs on all ports and sleep/wake works O.K. (though my iPhone resyncs each time due to the unload/load).

Link to comment
Share on other sites
bebop68
bebop68
Posted
Posted

I was wondering if there's a way to force the cards to appear 'builtin' on a real mac and if its relevant to the sleep/resume issue? I tried with a nec 720202 (I think the 'a' low power version) and it dumped the drives at sleep, and wouldn't remount them afterwards.

Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted

I was wondering if there's a way to force the cards to appear 'builtin' on a real mac and if its relevant to the sleep/resume issue? I tried with a nec 720202 (I think the 'a' low power version) and it dumped the drives at sleep, and wouldn't remount them afterwards.

Make the patch at 10056 and revert the patch at 10014. It's supposed to do that. Run the "ioreg" command from post #8 and check if it says "Card Type" Built-In or PCI.
Link to comment
Share on other sites
bebop68
bebop68
Posted
Posted (edited)

Thanks - I'm going to double check my patches but this is what I get:

 

 

+-o AppleUSBXHCI <class AppleUSBXHCI, id 0x10000022a, registered, matched, act$

| {

| "IOClass" = "AppleUSBXHCI"

| "CFBundleIdentifier" = "com.apple.driver.AppleUSBXHCI"

| "IOProviderClass" = "IOPCIDevice"

| "Card Type" = "PCI"

| "IOPCIClassMatch" = "0x0c033000"

| "IOUserClientClass" = "IOUSBControllerUserClient"

| "IOPowerManagement" = {"ChildrenPowerState"=0x3,"DevicePowerState"=0x3,"C$

| "IOProbeScore" = 0x0

| "IOPCITunnelCompatible" = Yes

| "this" = 0xffffff81c48e2000

| "IOMatchCategory" = "IODefaultMatchCategory"

| "ISTKeepAway" = 0x1

| }

|

+-o XHCI Root Hub SS Simulation@0 <class IOUSBRootHubDevice, id 0x100000267,$

| +-o AppleUSBHub <class AppleUSBHub, id 0x100000269, registered, matched, a$

| +-o IOUSBInterface@0 <class IOUSBInterface, id 0x10000026b, !registered, !$

+-o XHCI Root Hub USB 2.0 Simulation@0 <class IOUSBRootHubDevice, id 0x10000$

+-o AppleUSBHub <class AppleUSBHub, id 0x10000026e, registered, matched, a$

+-o IOUSBInterface@0 <class IOUSBInterface, id 0x100000270, !registered, !$

 

 

Maybe this is why it doesn't resume from sleep. This is with an fl1000 card. If the patches are correct is there anything else I can do to force 'built in'? I'm guessing something about how apple handles expresscard slots forces 'pci'.

 

Update - the patches are correct.

 

Update 2 - with nex 720202 card it registers as 'built in' but that card doesn't resume after sleep, and refuses to mount a drive after sleep also. weird.

Edited by bebop68
Link to comment
Share on other sites
Zenith432
Zenith432
Posted
  • Author
Posted
Maybe this is why it doesn't resume from sleep. This is with an fl1000 card. If the patches are correct is there anything else I can do to force 'built in'? I'm guessing something about how apple handles expresscard slots forces 'pci'.

 

Update - the patches are correct.

That means the chip reports that it doesn't support PME, so sleep can't be done. It will be reset during sleep and devices reenumerated.

 

Update 2 - with nex 720202 card it registers as 'built in' but that card doesn't resume after sleep, and refuses to mount a drive after sleep also. weird.
That means the chip reports itself as supporting PME, and sleep is done. But after resume, it reports an error, because during sleep it lost all electric power. AppleUSBXHCI leaves it in an unusable state.
Link to comment
Share on other sites
X-TRiAL
X-TRiAL
Posted
Posted

Thank you it worked for me. It enabled my USB 3.0 port, I can use it with standard USB 2.0 devices however not yet tried with a USB 3.0 device.

 

When a device is inserted and I sleep my machine, the system does not wake.

 

Thanks

Link to comment
Share on other sites
bebop68
bebop68
Posted
Posted

I've tried with the nec 720200a and got an overvolt warning which shut down the driver. I tried with an fl1009 card - like the asmedia it wouldn't hot swap. If inserted before bootup the vanilla drivers would load it, and mount drives, but they would get disconnected with sleep. The same happens with the patched driver! ioreg reports the card as 'pci' not 'built in'. So far the only card that reports as 'built in' is a nec 720202 but it still wouldn't resume after sleep.

 

I'm going to look at the 10.8.3 binary and see if the patches are applicable.

 

Update: It looks very different to me.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...