[GUIDE] USB Fix El Capitan 10.11

[VCH888]

tested minutes ago on my H87M-HD3 by editing dsdt instead of editing kext.

 

For 8 series & up w/ 10.11

 

I can choose which Device (####), such as Device (HS01) or Device (SSP1), of Device (XHC), not XHC1, in dsdt will be used or will be removed.  No more to edit kext. The first thing got to know which connections will be used by testing with editing kext. The disadvantage is that if you would use 10.10, you would lost some connections.

[chich0n]

Hey all !

 

I can't have my USB3 port work properly in 10.11 : they are recognize as usb2 port.

I have tried your solution but it changed nothing.

 

My MB : MSI Z97 GAMING 5

I join my vanilla DSDT.

 

 

I've try with your advice, but I have only one port USB3 working (the other USB3 port work as USB2).

I've changed the IOMatch to 8CB1 and I add ports in the SMbios section (iMac 14,2). I had only works on the USBXHCI.

 

Here's my dummy - have you got an idea ? (I used HS09 to HS14 and SSP3 to 6)

 

I don't use DSDT, I only use clover and some patches (as I do with 10.10)

 

thank you !

DummyUSBXHCIPCI.kext.zip

[RehabMan]

Can you take a look at 10.11 on your 4540s? My USB 3.0 ports (with multiplex) only run at 2.0 speed although I plugged 3.0 drive.

The reason the Multiplex patch doesn't work well is because the port numbers within the patch don't match the original DSDT.

 

In Yosemite, it seems to ignore the DSDT info.

In 10.11, it honors it when no injection for "ports" is present, and it uses "ports" as an override for DSDT when it is injected.

 

Non-working ports result from improper data provided to the kext.

 

Other notes:

- somewhere along the way, the system stopped responding to the items in the "multiplex" patch. I find on Yosemite USB3/USB2 on the ProBook works equally well with or without the Multiplex patch.

- used ACPIDebug to trace any calls to EHCA/EHCB...XHCA/XHCB... and they are not called

- not tried to see if MUXS is evaluated (will need to make it a method and trace via ACPIDebug).

- muxing is not working on Yosemite (no surprise there). With that model (MacBookPro9,2), at least, the kext seems to turn off all muxing.

- I can force a mux by setting PR2 to zero (read 7-series data sheet: XUSB2PR register at D0 in PCI config space for XHC controller), but I have to do it late enough to have an effect (I did it from SMCD.FCPU, which is called on a timer from ACPIPoller.kext)

 

So... muxing is a simple matter of setting the associated PR2 bits (3-0) to zero.

 

I also tried setting kUSBMuxEnabled (via AppleUSBMergeNub), but it didn't help. Either muxing is being phased out, or is not currently implemented, or there is some secret to it.

 

At any rate, with properly configured ports, I get USB3 speeds with USB3 devices on USB3 ports.

[pokenguyen]

...

- muxing is not working on Yosemite (no surprise there). With that model (MacBookPro9,2), at least, the kext seems to turn off all muxing.

...

You mean El Capitan? Cause we're using multiplex in 10.9/10.10 for 7-series so far.

[RehabMan]

You mean El Capitan? Cause we're using multiplex in 10.9/10.10 for 7-series so far.

It is not working on either. Plug a USB2 mouse into a USB3 port and you'll see that the Mux patching is ineffective (device will connect to XHC1, not EHC1).

 

It used to work, but stopped working and we just haven't noticed.

 

At least that's what I see with 10.10.3 and 10.11 on my 4540s.

 

In addition, if I patch without the Multiplex patch, I can't notice any difference in behavior (and nothing not working).

 

I can now see how to write a kext that would force muxing. A kext that would force -gux_defer_usb2 like behavior on without complex DSDT patches, and I'll probably give that a shot...

 

When I said "no surprise there" I meant since the methods (EHCA/EHCB... XHCA, XHCB) aren't even being called, we should not be surprised they are not effective.

 

---

 

BTW, I've resorted to renaming all USB controllers in DSDT so I can take control.

 

EHC1->EHC01

EHC2->EHC02

 

XCH1 (if was native XHC1) -> XHC

 

This way there is no matches against the AppleUSBMergeNub personalities that exist in the native kexts (for EHC1/EHC2/XHC1).

 

If you don't do that, both your injector and the native injector will run, resulting in a merge of native properties and those that you're providing in the injector. Although that can work in some scenarios, it doesn't work all the time. Classic case is wanting to change the port-count. Because there is no way to guarantee order, the native mergenub may run after yours, resulting in overwriting your intended port-count. Overwriting an existing port definition has similar problems. And, of course, it is impossible to remove ports that are provided already by the native mergenub properties.

 

By changing the names to something which is not in the native kexts, you have total control.

 

--

 

Edit: yes, a kext fix for muxing will be tricky because the native kext rewrites PR2 on wake from sleep (even though the setting is retained across sleep/wake cycle).

[pokenguyen]

This way there is no matches against the AppleUSBMergeNub personalities that exist in the native kexts (for EHC1/EHC2/XHC1).

 

If you don't do that, both your injector and the native injector will run, resulting in a merge of native properties and those that you're providing in the injector. Although that can work in some scenarios, it doesn't work all the time. Classic case is wanting to change the port-count. Because there is no way to guarantee order, the native mergenub may run after yours, resulting in overwriting your intended port-count. Overwriting an existing port definition has similar problems. And, of course, it is impossible to remove ports that are provided already by the native mergenub properties.

 

I change the topic kext from injector to dummy, but your method is quite good, especially when injector kext is better than dummy kext imo. Thanks.

[RehabMan]

I change the topic kext from injector to dummy, but your method is quite good, especially when injector kext is better than dummy kext imo. Thanks.

I see them as the same thing. Some injector kexts use a symlinked binary as if to pretend to be a real kext (eg. AppleHDA injectors).

 

It doesn't seem necessary in this case as we are not trying to inject anything from the 'Resources' directory.

 

So-called dummmy kexts (injectors using overridden bundle-id, symlinked binary, Resources overrides, other tricks [version#]) are generally not very reliable (they'll deactivate and require kext cache rebuild). And if you read the kernel extension documentation provided by Apple, you can see that dummy kexts break a bunch of rules documented by Apple. So I tend to avoid them unless they are genuinely necessary (AppleHDA case).

[Ccc]

This is an exciting work!

but I tried both method, does not work.

I can not see whether there is anything wrong with the DSDT.

In El Capitan, only 

Please help.

 

DSDT.aml.zip

 

[crusher]

I put all my USB in rear panel and one in front panel!!!!

 

 

[pokenguyen]

This is an exciting work!

but I tried both method, does not work.

I can not see whether there is anything wrong with the DSDT.

In El Capitan, only 

Please help.

 

IORegistry.png

USB.png

ELCapitan.png

DSDT.aml.zip

Did you remove the port restriction for your smbios in info.plist? Send me your kext. What is your smbios?

 

You should post .ioreg file in 10.11 btw.

[chich0n]

I've try with your advice, but I have only one port USB3 working (the other USB3 port work as USB2).

I've changed the IOMatch to 8CB1 and I add ports in the SMbios section (iMac 14,2). I had only works on the USBXHCI.

 

Here's my dummy - have you got an idea ? (I used HS09 to HS14 and SSP3 to 6)

 

I don't use DSDT, I only use clover and some patches (as I do with 10.10)

 

thank you !

Do you need more informations ?

[pokenguyen]

Do you need more informations ?

Chicon, please read the topic once again before doing.

 

Your USB device in DSDT is named XHC, so there is no port restriction, because by default Apple uses IONameMatch XHC1. However, Apple limits number of ports to 15, so only some first ports are recognized. You have to enable port restriction by renaming XHC in DSDT to XHC1 OR change IONameMatch in the dummy kext to XHC (Why do you change IONameMatch to 8C31 is out of my understanding), then add only valid ports to the dummy kext.

[Ccc]

Did you remove the port restriction for your smbios in info.plist? Send me your kext. What is your smbios?

 

You should post .ioreg file in 10.11 btw.

 

I also removed the port restriction in the info.plist ( IOProviderMergeProperties is empty)

 

Here is the ioreg file from yosemite and elcapitan.

please help.

 

 

 

IORegistry.zip

[chich0n]

Chicon, please read the topic once again before doing.

 

Your USB device in DSDT is named XHC, so there is no port restriction, because by default Apple uses IONameMatch XHC1. However, Apple limits number of ports to 15, so only some first ports are recognized. You have to enable port restriction by renaming XHC in DSDT to XHC1 OR change IONameMatch in the dummy kext to XHC (Why do you change IONameMatch to 8C31 is out of my understanding), then add only valid ports to the dummy kext.

 Ok i have misunderstood something. I will try to change change XHC1 to XHC in the dummy.

[pokenguyen]

I also removed the port restriction in the info.plist ( IOProviderMergeProperties is empty)

 

Here is the ioreg file from yosemite and elcapitan.

please help.

 

plist_edit.png

 

 

IORegistry.zip

Based on your Ioreg, El Capitan couldn't detect PRT1 and PRT2 from your DSDT. I think the problem is that you have both HUBN and RHUB in EHC1/EHC2 (My DSDT only has RHUB).

 

On your Yosemite ioreg, your USB is: EHC1/2 (1d000000) > HUB (1d100000) > port (1d160000)

 

Try adding HUBN, UsbConnector=0, port = 01000000 to your EHC1/EHC2 device, and post ioreg again.

[Riley Freeman]

When I originally tried booting El Cap on my Samsung laptop (with 7-series USB) it kernel panicked with USB errors. So after doing some reading earlier I removed all the USB-related DSDT edits and tried again. This time it worked perfectly.

 

All ports work (2x 2.0 and 2x 3.0) however everything gets listed in System Profiler under the USB 3.0 bus. I'm not sure if this is right. There is a USB 2.0 entry (2 in fact although the other is for the internal stuff like webcam and card reader). Looking at the IORegistry when connecting devices, everything happens under XHC and the devices connect to HSPx or SSPx depending on whether they're 2.0 or 3.0. I didn't pay this much attention to how USB worked when I ran Yosemite with the multiplex patch so I'm curious if this sounds like correct behaviour? Either way, I'm happy to have all ports working with no (apparent) need for the multiplex patch.

[RehabMan]

however everything gets listed in System Profiler under the USB 3.0 bus.... Looking at the IORegistry when connecting devices, everything happens under XHC and the devices connect to HSPx or SSPx depending on whether they're 2.0 or 3.0.

That seems to be the new way, at least on the hacks I've tried. Seems no more multiplexing from XHC->EHC1 (although it can be forced).

 

There is nothing wrong with it since the XHC controller can handle both USB2(HS) and USB3(SS).

 

It would be interesting if someone could post results (ioreg, System Information -> USB) from a real MacBookPro9,x which I think normally uses XCH->EHC1 multiplexing/passthru.

[RehabMan]

If anyone runs into non-working USB after sleep, it could be caused by DSDT.

 

I found that on one of my laptops, that DSDT was calling XSEL from _WAK (indirectly through XWAK). XSEL (or is it ESEL?) on this particular machine sets PR2 (32-bit register at offset 0xD0 in XHC PCI config) which controls how USB2 devices are routed to the ECH1 controller (USB2 deferring, as -gux_defer_usb2 does). Because it is routing USB2 devices to EHC1 and the new drivers in 10.11 don't expect it (system expects them to stay on the XHC controller), no USB ports devices were working after sleep.

 

Easy fix: Make XSEL and ESEL do nothing.

[crusher]

If anyone runs into non-working USB after sleep, it could be caused by DSDT.

 

I found that on one of my laptops, that DSDT was calling XSEL from _WAK (indirectly through XWAK). XSEL on this particular machine sets PR2 (32-bit register at offset 0xD0 in XHC PCI config) which controls how USB2 devices are routed to the ECH1 controller (USB2 deferring, as -gux_defer_usb2 does). Because it is routing USB2 devices to EHC1 and the new drivers in 10.11 don't expect it (system expects them to stay on the XHC controller), no USB ports devices were working after sleep.

 

Easy fix: Make XSEL do nothing.

Update your patches in http://raw.github.com/RehabMan/Laptop-DSDT-Patch/master

[RehabMan]

Update your patches in http://raw.github.com/RehabMan/Laptop-DSDT-Patch/master

I'm not sure it is universal yet. I'm doing this on my u430 which has its own set of USB patches.

 

I probably won't update much until 10.11 is final.

 

Currently, the only people that can get 10.11 are developers. So... any developer should know what to do and be able to read threads like this :-)

[Maniac10]

I can't make my Etron "EJ168" USB 3 ports work, everything looks fine on ioreg and system profile, any plugged device is recognized but they just don't work (USB3 pen drive isn't mounted, webcam isn't detected by FaceTime).

 

I've renamed the device XHC1 in my DSDT and have the USB 3 patches on KextsToPatch which worked fine in 10.10. Perhaps the patch needs to be updated?

 

[pokenguyen]

That seems to be the new way, at least on the hacks I've tried. Seems no more multiplexing from XHC->EHC1 (although it can be forced).

 

There is nothing wrong with it since the XHC controller can handle both USB2(HS) and USB3(SS).

 

It would be interesting if someone could post results (ioreg, System Information -> USB) from a real MacBookPro9,x which I think normally uses XCH->EHC1 multiplexing/passthru.

Thank you, I just remove the multiplex patch, and it does work on both 10.10 and 10.11. However I have to edit _PRW of EHC1, EHC2, XHC, LANC to get sleep work (similar to 8-series).

So what is the meaning of multiplex patch, is it used for 10.8?

Do you have 10.9 for testing?

If anyone runs into non-working USB after sleep, it could be caused by DSDT.

 

I found that on one of my laptops, that DSDT was calling XSEL from _WAK (indirectly through XWAK). XSEL (or is it ESEL?) on this particular machine sets PR2 (32-bit register at offset 0xD0 in XHC PCI config) which controls how USB2 devices are routed to the ECH1 controller (USB2 deferring, as -gux_defer_usb2 does). Because it is routing USB2 devices to EHC1 and the new drivers in 10.11 don't expect it (system expects them to stay on the XHC controller), no USB ports devices were working after sleep.

 

Easy fix: Make XSEL and ESEL do nothing.

I have both XSEL and ESEL function writing to PR2, but all my ports still work after sleep.

[RehabMan]

So what is the meaning of multiplex patch, is it used for 10.8?

Since I learned about the PR2 (XCH USB2 port routing) so recently, I've never looked into what exactly is going on in 10.8/10.9.

 

But the Multiplex patch injected methods (EHCx, XHCx) are simply manipulating the PR2 register.

 

I think there is likely better ways to force multiplex if we want to (working on a FakePCIID-based solution).

 

But I'm not sure multiplex is important in 10.11.

 

I would also like to see how the Multiplex patch works on the ProBook if properly coded.

[Riley Freeman]

With the multiplex patch removed (stock USB entries in DSDT) my USB ports are totally dead in Yosemite and earlier. It's only with El Capitan that my ports work without it.

[RehabMan]

With the multiplex patch removed (stock USB entries in DSDT) my USB ports are totally dead in Yosemite and earlier. It's only with El Capitan that my ports work without it.

Prior versions of OS X have a completely different USB stack as compared with 10.11.

 

We are dealing with a completely new thing here.