Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
Zenith432

Patched AppleUSBXHCI from OS 10.8.2

146 posts in this topic

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@ 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:

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Zenith432

 

Hello.

Please!

Can you add 32 bit support for i386?

Because native AppleUSBXHCI.kext has support both x86_64 and i386, when patched has only x86_64 and i can't use it with Core Duo CPU, non x86_64, only i386.

 

Thank you and check my solution for NEC USB 3.0 Cards, may be it help you in future.

Share this post


Link to post
Share on other sites

Hi zenith, it woks for me (thanks!) on GA-P55A-UD4

but If I put OSX in Stop (sleep), at resume USB3 device is disconnected (an error message appear).

maybe a DSDT issue like yours?

Could you help me to edit my DSDT (I have the _PTS Method) to have a full working USB3?

My DSDT here: http://www.mediafire...o2s4x9it4980ssv

Thank you a lot!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×