Contribute
Register

Any hope to have a "Guide to Recover your USB3 on El Capitan" for non expert people?

Status
Not open for further replies.
Joined
May 23, 2013
Messages
22
Motherboard
GA Z97M D3H
CPU
Intel i7 4770
Graphics
NVIDIA GTX 650 Ti 2 GB
Mac
  1. 0
Classic Mac
  1. 0
Mobile Phone
  1. Android
I mean for dummies, ' cause I've been reading the threads about this matter on this same forum and I've spent ten minutes to get rid of a real fish face. Seriously, I understand almost nothing. After two weeks learning how Clover works and configuring config.plist properly I realized that my USB 3.0 devices were under USB 2.0 hub with El Capitan. Everything else works fine, so If I have to stand with USB 2.0, I will, because it would be easier that USB 2.0 became spontaneously 3.0 than I understand how people are fixing it.

Entropic.
 
RehabMan has said he will write a guide/s once the final release is out, trying to address some of the USB issues brought on by El Capitan.. I don't exactly think it will be the "for dummies" guide, but he is pretty easy to follow, in my experience..

It will be interesting to see what it contains, as it seems each board/hardware configuration can have its own unique issues..
 
Additionally, RehabMan is one of the contributors to Clover. so we might see a Clover solution...maybe...hopefully. I also share your confusion, entropic. (Your name brings back memory of my engineering days.)
 
Additionally, RehabMan is one of the contributors to Clover. so we might see a Clover solution...maybe...hopefully. I also share your confusion, entropic. (Your name brings back memory of my engineering days.)

The USB problem, IMHO, is not solvable in the bootloader. It is more of an ACPI/kext issue...

Clover has nice tools that can be used to help solve (eg. DSDT patches via config.plist/ACPI/DSDT/Patches).
 
The problems, as I understand it (which is pretty dimly), are these:
  1. Your motherboard manufacturer enumerates the available USB ports, but they might be lying to you (errors in the DSDT)
  2. You can attempt to manually verify the available USB ports, but your eyes might be lying to you (overlooking unconnected headers or USB ports assigned to m.2 slots, and etc.)
  3. Even with the correct list of available ports, Apple may have overridden the selection based on your system definition (for controllers in the DSDT named "XHC1" and etc.)
  4. Even if you rename your controllers to avoid that, there are hard limits to the number of USB ports per controller, aggravated by all USB3 ports being double-counted
  5. Even if you reallocate ports across controllers to avoid that, somehow the motherboard manufacturer may have defeated that by some kind of hardwiring preventing certain ports from being associated with certain controllers
It seems like #1 is the main problem as far as an automated Clover solution goes -- Clover could automatically do stuff based on the DSDT information it sees, but if that information is wrong, Clover might not end up doing anything useful.

Is that a fair summary?
 
The problems, as I understand it (which is pretty dimly), are these:
  1. Your motherboard manufacturer enumerates the available USB ports, but they might be lying to you (errors in the DSDT)
  2. You can attempt to manually verify the available USB ports, but your eyes might be lying to you (overlooking unconnected headers or USB ports assigned to m.2 slots, and etc.)
  3. Even with the correct list of available ports, Apple may have overridden the selection based on your system definition (for controllers in the DSDT named "XHC1" and etc.)
  4. Even if you rename your controllers to avoid that, there are hard limits to the number of USB ports per controller, aggravated by all USB3 ports being double-counted
  5. Even if you reallocate ports across controllers to avoid that, somehow the motherboard manufacturer may have defeated that by some kind of hardwiring preventing certain ports from being associated with certain controllers
It seems like #1 is the main problem as far as an automated Clover solution goes -- Clover could automatically do stuff based on the DSDT information it sees, but if that information is wrong, Clover might not end up doing anything useful.

Is that a fair summary?

Clover can't really do much about this based on DSDT because DSDT is often inaccurate many times due to the DSDT not knowing what OS it is running on, or just because the OEM made a mistake (eg. not recognizing Linux/Windows when running on Darwin). Windows either interprets _UPC differently than 10.11 or doesn't use it at all (or has workarounds like crazy).

It goes something like this:
- DSDT contains information on USB ports, and ports on built-in USB hubs
- DSDT may be wrong
- Apple may have found DSDT wrong in several Apple products, so they implemented a mechanism to override DSDT (port injectors)
- The Apple port injectors are matched on ACPI name of the controller and SMBIOS
- The Apple port injectors will override your DSDT (correct or not) if the port injectors match
- Renaming the controllers to prevent a match can be used to avoid the Apple provided port injectors, in which case, the system falls back on DSDT (which still may be wrong)
- After the ports are renamed, should your DSDT provide inaccurate details about the USB port topology, you can create a port injector just like Apple did for their own computers (you could also fix DSDT _UPC, but it is easier to do a port injector)
- Regardless, there is a limit of 15 ports per controller (or hub)
- USB3 ports count as two when both the USB2 and USB3 component are routed to the XHC controller
- USB2 ports can be routed from XHC to EHC via registers on the XHC chip
- The built-in drivers have support for this routing (muxing), but it is not well understood (there is a relationship between special DSDT methods and USB port injector data)
- FakePCIID_XHCIMux.kext can be used to force the USB2 component on XHC to EHC
- FakePCIID_XHCIMux.kext can block writes to the USB2 routing registers when such writes occur in the OS X USB drivers.
- BIOS settings affect what FakePCIID_XHCIMux does (it honors BIOS setting for the USB2 port routing mask)
- FakePCIID_XHCIMux.kext cannot block writes that occur from ACPI space (evidently AppleACPIPlatform.kext doesn't go through IOPCIDevice to do these writes)
- As a result, it is possible to have DSDT breaking things as it relates to USB2 port routing, especially on wake from sleep
- Such writes to the port routing registers from ACPI space can be fixed by ACPI patches (disabling XWAK/ESEL/XSEL), or sometimes by simulating a certain version of Windows (_OSI->XOSI mapping)

So... solutions employed depend on what conditions are actually happening.

Solutions:
- BIOS settings for USB2 port routing on XHC ("auto" vs. "smart auto" vs. "enabled")
- renaming EHCx->EH0x to avoid built-in port injectors
- FakePCIID_XHCIMux to enforce USB2 port routing on XHC
- DSDT patches to simulate Windows (various versions) when running Darwin
- DSDT patches to avoid writes to port routing registers on XHC (nullifying XWAK, ESEL, XSEL)
- custom port injectors to match actual port configuration
 
I use PJALMs gigabyte DSDT patches from here
http://pjalm.com/forums/index.php?topic=7.0
Which have made my board 100% perfect up until now. I am curious if these will cause issues with 10.11 USB, or actually help it? Or if these patches will need any modifications? I don't really want to drop them as they correct many issues perfectly and are perfectly tailored to board so, to me anyways, a bit better than guesswork in clover what to check or uncheck based on board.
 
OK, I have again my fish-face after reading your posts. I see, all the same, that it is not a problem that you can automatize and it has differents faces in differents motherboards. Well, It's good to see you having such a technical conversation on a thread open by me. I'm proud. And I'll follow the thread... Maybe I will finishing understanding the topic.


Thanks to everybody

Entropic.
 
I use PJALMs gigabyte DSDT patches Which have made my board 100% perfect up until now. I am curious if these will cause issues with 10.11 USB, or actually help it?

I looked at the GA-H87N-WIFI patch there. It makes USB worse under 10.11. Unpatched, USB3 works and all USB ports on the board and my case work. The patch changes XHC to XHC1, which causes the wonky Apple rules to come into force, and the USB ports on my back panel stop working (though the ones on the case thankfully still worked so I had a keyboard to revert!).

The needed patch to the patch is only a couple lines to stop it from renaming XHC to XHC1, but what's in the repository right now is not good for the GA-H87N-WIFI for 10.11.

That was the only patch set I looked at.
 
I've settled on having it on Smart Auto. It's the only way USB works (enabled doesn't recognize any, auto only 2.0). Smart Auto at least gives me access to most ports, even though 3.0 shows as 2.0 (weirdly 3.0 shows separately as a Hub but nothing gets routed to it). Just have to wait a few weeks till things get sorted, I suppose.
 
Status
Not open for further replies.
Back
Top