VCH888 Posted July 2, 2015 Share Posted July 2, 2015 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. 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 More sharing options...
ervinke2 Posted July 2, 2015 Share Posted July 2, 2015 Try to change Device (EHCI) to Device (ECH1) in dsdt. Thank you! I changed it in my DSDT, and changed SMBios from MBP5,1 to MBP3,1 and now it's working. Link to comment Share on other sites More sharing options...
mendietinha Posted July 2, 2015 Share Posted July 2, 2015 you do know that i pointed the very same thing one post before, right? Link to comment Share on other sites More sharing options...
TheRacerMaster Posted July 3, 2015 Share Posted July 3, 2015 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 More sharing options...
RehabMan Posted July 3, 2015 Share Posted July 3, 2015 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. 4 Link to comment Share on other sites More sharing options...
Riley Freeman Posted July 4, 2015 Share Posted July 4, 2015 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 More sharing options...
RehabMan Posted July 4, 2015 Share Posted July 4, 2015 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) 1 Link to comment Share on other sites More sharing options...
FranticJohny Posted July 4, 2015 Share Posted July 4, 2015 Great work RehabMan FakePCIID_XHCIMux works for me. Link to comment Share on other sites More sharing options...
VCH888 Posted July 4, 2015 Share Posted July 4, 2015 @ RehabMan Thank you for FakePCIIC_XHCIMux that is working on my H87M-HD3. update: XHCI Enabled in UEFI >> lost usb2 devices if using this fake id. Link to comment Share on other sites More sharing options...
RehabMan Posted July 4, 2015 Share Posted July 4, 2015 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 More sharing options...
VCH888 Posted July 5, 2015 Share Posted July 5, 2015 @ 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 More sharing options...
RehabMan Posted July 5, 2015 Share Posted July 5, 2015 @ 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 More sharing options...
mendietinha Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
RehabMan Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
mendietinha Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
RehabMan Posted July 5, 2015 Share Posted July 5, 2015 xhc. If you use XHCIMux, they'll connect to EHC1. 1 Link to comment Share on other sites More sharing options...
xmen107 Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
RehabMan Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
xmen107 Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
RehabMan Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
xmen107 Posted July 5, 2015 Share Posted July 5, 2015 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 More sharing options...
robi39 Posted July 6, 2015 Share Posted July 6, 2015 Could somebody please tell me, if my USB ports working correctly, by looking at the ioreg file? Robert’s iMac.zip Link to comment Share on other sites More sharing options...
Riley Freeman Posted July 8, 2015 Share Posted July 8, 2015 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. 2 Link to comment Share on other sites More sharing options...
xmen107 Posted July 8, 2015 Share Posted July 8, 2015 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... Link to comment Share on other sites More sharing options...
pokenguyen Posted July 9, 2015 Author Share Posted July 9, 2015 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. 1 Link to comment Share on other sites More sharing options...
Recommended Posts