Jump to content

Patched AppleUSBXHCI from OS 10.8.2

USB 3 AppleUSBXHCI

  • Please log in to reply
135 replies to this topic

#41
04152viki

04152viki

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 774 posts

Is it possible to do this with Clover's kext patcher?


yes

#42
alexanderq

alexanderq

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 232 posts
  • Gender:Male
Hello 04152viki

Can you please tell us how to do it with Clover's kext patcher.

#43
04152viki

04152viki

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 774 posts
Attached File  config.plist.zip   542bytes   85 downloads

#44
alexanderq

alexanderq

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 232 posts
  • Gender:Male
Thank you very much.

#45
shiecldk

shiecldk

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 233 posts
  • Gender:Male
  • Location:Taiwan

Hello 04152viki

Can you please tell us how to do it with Clover's kext patcher.

Go see this post.

I use otools to decompile AppleUSBXHCI just like what Zenith432 did.

#46
newnekton1

newnekton1

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 132 posts
Hi Zenith 432,
First thanks for all your effort on this USb3 problem.
I have the same problem with the USB Drive showing that it is mounted under the High-Speed port when it is in fact the SuperSpeed port. The command you suggested in post #8 gives Built-in as the Card Type property.
Here is the output:

Last login: Thu Feb 28 17:54:15 on console
-bash-3.2$ ioreg -xrc AppleUSBXHCI
+-o AppleUSBXHCI <class AppleUSBXHCI, id 0x100000201, registered, matched, act$
| {
| "IOClass" = "AppleUSBXHCI"
| "CFBundleIdentifier" = "com.apple.driver.AppleUSBXHCI"
| "IOProviderClass" = "IOPCIDevice"
| "Card Type" = "Built-in"
| "IOPCIClassMatch" = "0x0c033000"
| "IOUserClientClass" = "IOUSBControllerUserClient"
| "IOPowerManagement" = {"ChildrenPowerState"=0x4,"DevicePowerState"=0x3,"C$
| "IOProbeScore" = 0x0
| "IOPCITunnelCompatible" = Yes
| "this" = 0xffffff80d6cd8000
| "IOMatchCategory" = "IODefaultMatchCategory"
| "ISTKeepAway" = 0x1
| }
|
+-o XHCI Root Hub SS Simulation@0 <class IOUSBRootHubDevice, id 0x100000203,$
| +-o AppleUSBHub <class AppleUSBHub, id 0x100000239, registered, matched, a$
| +-o IOUSBInterface@0 <class IOUSBInterface, id 0x10000023d, !registered, !$
+-o XHCI Root Hub USB 2.0 Simulation@0 <class IOUSBRootHubDevice, id 0x10000$
| +-o AppleUSBHub <class AppleUSBHub, id 0x100000254, registered, matched, a$
| +-o IOUSBInterface@0 <class IOUSBInterface, id 0x100000256, !registered, !$
+-o My Passport 0740@3c100000 <class IOUSBDevice, id 0x1000005e2, registered$
+-o IOUSBCompositeDriver <class IOUSBCompositeDriver, id 0x1000005e5, !reg$
+-o MSC Bulk-Only Transport@0 <class IOUSBInterface, id 0x1000005e6, regis$
+-o IOUSBMassStorageClass <class IOUSBMassStorageClass, id 0x1000005e8, $
+-o IOSCSILogicalUnitNub@0 <class IOSCSILogicalUnitNub, id 0x1000005ea$
| +-o IOSCSIPeripheralDeviceType00 <class IOSCSIPeripheralDeviceType00$
| +-o IOBlockStorageServices <class IOBlockStorageServices, id 0x100$
| +-o IOBlockStorageDriver <class IOBlockStorageDriver, id 0x10000$
| +-o WD My Passport 0740 Media <class IOMedia, id 0x1000005f4, $
| +-o IOMediaBSDClient <class IOMediaBSDClient, id 0x1000005f5$
| +-o IOGUIDPartitionScheme <class IOGUIDPartitionScheme, id 0$
| +-o EFI System Partition@1 <class IOMedia, id 0x1000005fa,$
| | +-o IOMediaBSDClient <class IOMediaBSDClient, id 0x10000$
| +-o TIMEMACHINE@2 <class IOMedia, id 0x1000005fb, register$
| +-o IOMediaBSDClient <class IOMediaBSDClient, id 0x10000$
+-o IOSCSILogicalUnitNub@1 <class IOSCSILogicalUnitNub, id 0x1000005f0$
+-o SCSITaskUserClientIniter <class SCSITaskUserClientIniter, id 0x1$

-bash-3.2$

Rather than use your patched kext, I used the kext edit function in Clover's config.plist as shown here:


<key>KernelAndKextPatches</key>
<dict>
<key>KextsToPatch</key>
<dict>
<key>0</key>
<dict>
<key>Find</key>
<data>
PQABDw==
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
PQAADw==
</data>
</dict>
<key>1</key>
<dict>
<key>Find</key>
<data>
dVtJiw==
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
61tJiw==
</data>
</dict>
<key>2</key>
<dict>
<key>Find</key>
<data>
PQABDw==
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
PQAADw==
</data>
</dict>
<key>3</key>
<dict>
<key>Find</key>
<data>
gUkIAABA
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
gUkIAAAA
</data>
</dict>
<key>4</key>
<dict>
<key>Find</key>
<data>
RCQIAABA
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
RCQIAAAA
</data>
</dict>
<key>5</key>
<dict>
<key>Find</key>
<data>
AEAAQYtG
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
AAAAQYtG
</data>
</dict>
<key>6</key>
<dict>
<key>Find</key>
<data>
AcaDfw==
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
AMaDfw==
</data>
</dict>
<key>7</key>
<dict>
<key>Find</key>
<data>
dSZIi7vo
</data>
<key>Name</key>
<string>AppleUSBXHCI</string>
<key>Replace</key>
<data>
6yZIi7vo
</data>
</dict>
</dict>
</dict>

Hope this helps you to figure out the problem.

#47
newnekton1

newnekton1

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 132 posts
TimeWalker,
How did you make this patch using KextPatcher in Clover.
Could you paste the config.plist line here for me to try?
Thanks.

Cool, thank you very much for this research!
The sleep patch at offset 10014 has cured the issue that has been plaguing my FL1009 controller on my Vostro 3450 laptop. Controller used to work absolutely fine, but refused to work after sleep. I use Jettison https://itunes.apple...son/id447430809 to unmount usb drives before sleep and remount afterwards. 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!



#48
Maniac10

Maniac10

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPipPip
  • 1,248 posts
  • Gender:Not Telling

Hi Zenith 432,
First thanks for all your effort on this USb3 problem.
I have the same problem with the USB Drive showing that it is mounted under the High-Speed port when it is in fact the SuperSpeed port. The command you suggested in post #8 gives Built-in as the Card Type property.


I also have the same issue with Clover's patch (can't remember with the patched kext, I'll try later). The USB3 ports seems to be duplicated in System Info.

Attached File  Captura de pantalla 2013-02-28 a la(s) 12.52.48.png   32.67KB   5 downloads

#49
alexanderq

alexanderq

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 232 posts
  • Gender:Male
Same for me and when i insert a usb device in usb3 ports in OS X it shows it under the usb 2 ports

#50
Zenith432

Zenith432

    InsanelyMac Sage

  • Developers
  • 460 posts
  • Gender:Male
I've resolved the Sleep issue on my system. Discovered that it was due to an error in the DSDT, not the xHC.

I've fixed the DSDT, eliminated the bottom two patches in the patch-list in post #1, and now sleep works, including being able to wake the system with a USB keyboard connected to the xHC (a.k.a. PME).

Hardware: Intel motherboard with H67 chipset, Renesas uPD720200F1 with most recent firmware (3.0.3.4).
  • First, just to set the record straight, the uPD720200 does support chip-internal restore, contrary to what I said in post #23. This is a mandatory feature in the xHC spec.
  • Topology-wise, Intel Panther-Point is integrated into the south-bridge (PCH), so it is connected directly to the PCIe host-bridge (root complex.) All other xHC chips, whether in a separate chip on the motherboard, or PCIe expansion card, are connected behind a PCIe root port (PCI2PCI bridge.) In other words, have one more-level of indirection in the data path to RAM/processor core.
  • The board's DSDT has a method called IOKS that wrecks power-management. It attempts to access the PS/2 keyboard and mouse, and goes into an infinite loop, because H67 doesn't have a PS/2 controller (!).
  • DSDT has a method call _PTS ("prepare to sleep") that is executed by AppleACPIPlatformExpert.kext before the system goes to sleep or shuts down.
  • _PTS calls IOKS to do something with PS/2 keyboard/mouse, and hangs.
  • AppleACPIPlatformExpert has a watchdog-timer on this ACPI method, and times out after 75 seconds, decides _PTS is in an infinite loop, aborts it, and proceeds to complete the sleep/shutdown sequence anyway.
  • In _PTS, after the code that calls IOKS, there is code to prepare the PCIe root ports for PME.
  • As a result of the abort of _PTS, the PCIe root ports are not properly prepared for sleep.
  • Since PME is not enabled on the root port, the xHC chip connected to the port does not receive Aux power during sleep. This causes the chip to lose all context, and come back from sleep as if it was just turned on from a power-off state.
So the result of the problem with IOKS was
  • Sleep and shutdown process would take 75 seconds...
  • PCIe devices on root ports were completely shut down during sleep and could not recover any state existing before the sleep.
It took quite a bit of work to figure this out...

P.S. The resolution was to eliminate IOKS and all calls to IOKS in the DSDT. I also removed the nonexistent PS/2 devices, along with non-existent sleep-button, floppy controller and LPT port.

#51
newnekton1

newnekton1

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 132 posts
So could we achieve the same using Clover's KextPatcher to edit AppleACPIPlatformExpert.kext if possible?

#52
Zenith432

Zenith432

    InsanelyMac Sage

  • Developers
  • 460 posts
  • Gender:Male

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

#53
bebop68

bebop68

    InsanelyMac Protégé

  • Members
  • Pip
  • 23 posts
Awesome work Zenith432, have you posted the file minus the last two patches?

#54
Zenith432

Zenith432

    InsanelyMac Sage

  • Developers
  • 460 posts
  • Gender:Male

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
  • Allows USB devices like keyboards, mice or modems on the xHC to wake the system.
  • 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
  • suspend/resume with PME enabled.
  • 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.

#55
newnekton1

newnekton1

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 132 posts
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, 01 March 2013 - 08:45 AM.


#56
TimeWalker75a

TimeWalker75a

    InsanelyMac Legend

  • Gurus
  • 1,149 posts
  • Gender:Male

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.

#57
bebop68

bebop68

    InsanelyMac Protégé

  • Members
  • Pip
  • 23 posts
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, 02 March 2013 - 02:57 AM.


#58
newnekton1

newnekton1

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 132 posts
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.



#59
TimeWalker75a

TimeWalker75a

    InsanelyMac Legend

  • Gurus
  • 1,149 posts
  • Gender:Male

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

#60
shiecldk

shiecldk

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 233 posts
  • Gender:Male
  • Location:Taiwan

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.





Also tagged with one or more of these keywords: USB 3, AppleUSBXHCI


1 user(s) are reading this topic

1 members, 0 guests, 0 anonymous users


© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy