Jump to content

[GUIDE] USB Fix El Capitan 10.11


830 posts in this topic

Recommended Posts

i'm using macpro6,1 smbios, and my front panel usb2 wont work but usb3 just ran fine both front and back.

then i'm looking into my dsdt and the usbehcipci on iousb kext,

there's only 1 EHCI (EHCI1) in the info.plist, but my board have 2 EHCI (EHCI1 and EHCI2).

.....

my board is GA-B75-HD3

Thanks

I renamed EHC1 to EHCA and EHC2 to EHCB for my Z77 and removed Device (####) from XHC. So, I don't have to use any dummy.

 

post-93383-0-19793100-1435845768_thumb.jpg

I have a problem with my USB2.0 too. After I removed the port restriction it's still not working. And then I realized my USB ports in my DSDT aren't under any EHC. I don't know, if it's a problem. Anybody have any idea?

Try to change Device (EHCI) to Device (ECH1) in dsdt.

Link to comment
Share on other sites

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

 

Wow, good find. I repatched my DSDT and excluded the USB 3.0 muxing patch and everything is working fine in Beta 2 (although I renamed the XHC device to XHC1). Tested with USB 2 mouse in USB 3 ports, USB 2 flash drives in USB 3 ports, and combinations of them. Everything works. Nice to know it's no longer needed. Haven't tested 10.10.4 yet.

Link to comment
Share on other sites

Wow, good find. I repatched my DSDT and excluded the USB 3.0 muxing patch and everything is working fine in Beta 2 (although I renamed the XHC device to XHC1). Tested with USB 2 mouse in USB 3 ports, USB 2 flash drives in USB 3 ports, and combinations of them. Everything works. Nice to know it's no longer needed. Haven't tested 10.10.4 yet.

I've got a new solution for XHC->EHC routing (so-called 'muxing') in FakePCIID_XHCIMux.kext. Just in case it is needed...

 

There appears to be code in 10.11 to deal with ACPI MUXS objects, but I'm not certain how to make it work. And I'm not sure if making it work Apple's way has any advantage over FakePCIID_XHCIMux.kext. I'll find out if I ever get a Multiplex patch to work correctly.

  • Like 4
Link to comment
Share on other sites

I've got a new solution for XHC->EHC routing (so-called 'muxing') in FakePCIID_XHCIMux.kext. Just in case it is needed...

 

With FakePCIID_XHCIMux.kext USB 2.0 devices now show up under the USB 2.0 bus in 10.11 on my Samsung laptop.

 

The USB ports were dead in 10.10 after removing the old DSDT multiplexing fix. They work again with this kext.

Link to comment
Share on other sites

With FakePCIID_XHCIMux.kext USB 2.0 devices now show up under the USB 2.0 bus in 10.11 on my Samsung laptop.

 

The USB ports were dead in 10.10 after removing the old DSDT multiplexing fix. They work again with this kext.

Congratulations for finding it and building it yourself.

 

I uploaded a new build of FakePCIID to bitbucket so others can enjoy/test: https://github.com/RehabMan/OS-X-Fake-PCI-ID

(please read the README)

  • Like 1
Link to comment
Share on other sites

update: XHCI Enabled in UEFI >> lost usb2 devices if using this fake id.

It probably sets PR2M differently (PR2M limits USB2 port forwarding via PR2 when RM,pr2-honor-pr2m is non-zero). You can see options for this in the kext "RM,pr2-honor-pr2m" for example.

 

You can use _DSM injection to inject overrides for the default values used by the kext.

 

Refer to the README and the chipset datasheet for more info.

 

As an example... to override RM,pr2-honor-pr2m:

into method label _DSM parent_adr 0x00140000 remove_entry;
into device name_adr 0x00140000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n
    Return (Package()\n
    {\n
        "RM,pr2-honor-pr2m", Buffer() { 0 },\n
    })\n
}\n
end;
Any of the other values supported by the kext can be be overridden.

 

Note: If you're already using _DSM injection for USB properties, you'd have to add this property:

into method label _DSM parent_adr 0x00140000 remove_entry;
into device name_adr 0x00140000 insert
begin
Method (_DSM, 4, NotSerialized)\n
{\n
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }\n
    Return (Package()\n
    {\n
        "RM,pr2-honor-pr2m", Buffer() { 0 },\n
        "AAPL,clock-id", Buffer() { 0x02 },\n
        "built-in", Buffer() { 0x00 },\n
        "subsystem-id", Buffer() { 0x70, 0x72, 0x00, 0x00 },\n
        "subsystem-vendor-id", Buffer() { 0x86, 0x80, 0x00, 0x00 },\n
        "AAPL,current-available", 2100,\n
        "AAPL,current-extra", 2200,\n
        "AAPL,current-extra-in-sleep", 1600,\n
        "AAPL,device-internal", 0x02,\n
        "AAPL,max-port-current-in-sleep", 2100,\n
    })\n
}\n
end;
Link to comment
Share on other sites

@ RehabMan

 

Thank you for your help. Unfortunately, I could not make it and maybe it's beyond my knowledge.

 

 

 
When I set XHCI mode to be enabled, the system will use XHCI controller instead of EHCI for USB2.0 devices. Both Winodos 7 and OS X 10.10/11 showed all usb devices were controlled by XHCI only. 
 
There was no any problem if I set XHCI mode to be AUTO/SMART AUTO. The fake-id kext would force usb2.0 devices to be controlled by EHCI. 
 
For Gigabyte 8/9 series, I think the best option to get all devices working on OS X 10.11 is to set XHCI mode to be AUTO/SMART AUTO and install fake-id kexts and inject all six XHCI ports.  Anyhow, it’s up to anyone who may decide which/how ports are used.  
Link to comment
Share on other sites

@ RehabMan

 

Thank you for your help. Unfortunately, I could not make it and maybe it's beyond my knowledge.

 

 

 

When I set XHCI mode to be enabled, the system will use XHCI controller instead of EHCI for USB2.0 devices. Both Winodos 7 and OS X 10.10/11 showed all usb devices were controlled by XHCI only.

Like I said, these options likely control what the BIOS puts into PR2M. You should look at system.log for FakePCIID related messages.

 

The BIOS can set PR2M bits to zero indicating those ports "should not" be forwarded to EHC1 via PR2. FakePCIID honors this if "RM,pr2-honor-pr2m" is non-zero. You can override it as I noted above.

 

There was no any problem if I set XHCI mode to be AUTO/SMART AUTO. The fake-id kext would force usb2.0 devices to be controlled by EHCI. 

 

For Gigabyte 8/9 series, I think the best option to get all devices working on OS X 10.11 is to set XHCI mode to be AUTO/SMART AUTO and install fake-id kexts and inject all six XHCI ports.  Anyhow, it’s up to anyone who may decide which/how ports are used.

Smart auto setting probably makes the most sense.

Link to comment
Share on other sites

Like I said, these options likely control what the BIOS puts into PR2M. You should look at system.log for FakePCIID related messages.

 

The BIOS can set PR2M bits to zero indicating those ports "should not" be forwarded to EHC1 via PR2. FakePCIID honors this if "RM,pr2-honor-pr2m" is non-zero. You can override it as I noted above.

 

 

Smart auto setting probably makes the most sense.

 

Thanks. Your kext solved my usb problem in yosemite. i dont know why but in el capitan works perfectly without any edit or kext.

Link to comment
Share on other sites

Thanks. Your kext solved my usb problem in yosemite. i dont know why but in el capitan works perfectly without any edit or kext.

From what I see, 10.11 has a more flexible USB system. The ability to override ACPI via plist is helpful. Seems as if pre-10.11 had hardcoded configuration depending on Mac model, new code is more flexible/data driven/ACPI driven.

 

On 10.11, without XHCIMux, are your USB devices attaching to XHC or EHC1?

Link to comment
Share on other sites

From what I see, 10.11 has a more flexible USB system. The ability to override ACPI via plist is helpful. Seems as if pre-10.11 had hardcoded configuration depending on Mac model, new code is more flexible/data driven/ACPI driven.

 

On 10.11, without XHCIMux, are your USB devices attaching to XHC or EHC1?

 

xhc.

Link to comment
Share on other sites

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.

Hi RehabMan i need your help please...my USB 2.0 not working after sleep i don't know what is wrong in my DSDT can you see my dsdt please? in Yosemite i have full sleep working. 

DSDT.aml.zip

Link to comment
Share on other sites

Hi RehabMan i need your help please...my USB 2.0 not working after sleep i don't know what is wrong in my DSDT can you see my dsdt please? in Yosemite i have full sleep working. 

No XSEL/ESEL in your DSDT. Also, no XHC device, so I assume no USB3. Your issue is different. Check ioreg to determine more about what is going on. Also, maybe some clues in system.log.

Link to comment
Share on other sites

No XSEL/ESEL in your DSDT. Also, no XHC device, so I assume no USB3. Your issue is different. Check ioreg to determine more about what is going on. Also, maybe some clues in system.log.

I tried that but I can not see what is wrong... :(

Link to comment
Share on other sites

I tried that but I can not see what is wrong... :(

Did you read/follow post #1 this thread?

 

What did you see in ioreg/system.log post-wake?

Link to comment
Share on other sites

Did you read/follow post #1 this thread?

 

What did you see in ioreg/system.log post-wake?

Yes I did everything as in the first post removed the restrictions to the Dummykext ... after that recognized the port USB 2.0 ....but broken sleep.. I do not know now what happened to my system does not start more ... already formatted the disk and will having to install again ... something is wrong and not found out what it is ... but later post here my log ...is frustrating these new alterations in USB i never had problems for years...sorry my english

Link to comment
Share on other sites

DP3 brought good and bad news here.

 

On the good side, I no longer have to disable the ASM1042 controller in the BIOS to be able to boot El Cap. It no longer KPs when the controller is enabled.

 

On the bad side, my laptop is hosed. It's giving the same boot KP I was getting before I removed the multiplex DSDT edits. I removed the XHCIMux.kext just to see if it would make any difference but it doesn't. Pity as it was working perfectly with DP2.

  • Like 2
Link to comment
Share on other sites

Hey guys.... for me DummyUSBEHCIPCI.kext with removed restrictions now cause kernel panic at boot on my laptop no more recognize cam or card reader....DummyUSBEHCIPCI.kext working with DP2...

Try this:

- Copy the info.plist from the AppleUSBEHCIPCI.kext to overwrite the info.plist of dummy kext.

- CHange version in info.plist to 900.

- Remove port restriction.

- Install Dummy again.

  • Like 1
Link to comment
Share on other sites

×
×
  • Create New...