USB 3.0? Previous FakePCIID/FakePCIID_XHCIMux.kext patch not working...

[jmmusick]

Hi All,

I managed to get my El Capitan build updated to Sierra, today. I've got nearly everything working, but my USB 3.0 controller is no longer working.

When I built El Capitan, after tons of trouble, I found I only needed to do the following to get it to work:

Patch:

Name: AppleUSBXHCIPCI
Find: 83BD8CFEFFFF10
Replace: 83BD8CFEFFFF16

Then, I needed to install FakePCIID.kext and FakePCIID_XHCIMux.kext with a Kext Installer. I've done that again with from the latest download here:
https://bitbucket.org/RehabMan/os-x-fake-pci-id/downloads

I'll be messing with this a bit more tonight, but wasn't sure if anyone else had this issue after the upgrade. I'm running a Asus-H97 board.

 

[RehabMan]

Hi All,

I managed to get my El Capitan build updated to Sierra, today. I've got nearly everything working, but my USB 3.0 controller is no longer working.

When I built El Capitan, after tons of trouble, I found I only needed to do the following to get it to work:

Patch:

Name: AppleUSBXHCIPCI
Find: 83BD8CFEFFFF10
Replace: 83BD8CFEFFFF16

Then, I needed to install FakePCIID.kext and FakePCIID_XHCIMux.kext with a Kext Installer. I've done that again with from the latest download here:
https://bitbucket.org/RehabMan/os-x-fake-pci-id/downloads

I'll be messing with this a bit more tonight, but wasn't sure if anyone else had this issue after the upgrade. I'm running a Asus-H97 board.

The port limit patch is not recommended for long-term use. You should have created a custom injector or used USBInjectAll and a custom SSDT to specifically inject the ports you need in order to stay under the 15-port limit.

See guide: http://www.tonymacx86.com/threads/guide-10-11-usb-changes-and-solutions.173616/

As for the reason for the failure now, there is a new port limit patch for 10.12... the 10.11 patch doesn't apply. So you're probably hitting the port limit. But you shouldn't have been relying upon the port limit patch anyway.

 

[jmmusick]

Check in your ioreg to see what your native device-id is for XHC.

I'm seeing a couple of things:

device-id, Data, <b1 8c 00 00>
IOName, String, pci8086,8cb1

I'm not sure what I'd do with the device ID, but would I be correct in assuming my problem might be using 8086:8XXX instead of 8086:8cb1?

Update: I tried that. Still seeing all HS01-HS14 ports, including those that should be excluded.

 

[RehabMan]

I'm seeing a couple of things:

device-id, Data, <b1 8c 00 00>
IOName, String, pci8086,8cb1

I'm not sure what I'd do with the device ID, but would I be correct in assuming my problem might be using 8086:8XXX instead of 8086:8cb1?

Update: I tried that. Still seeing all HS01-HS14 ports, including those that should be excluded.

SSDT must match on "8086_8cb1".

 

[jmmusick]

SSDT must match on "8086_8cb1".

Meaning I should have that define like this?

            // XHC overrides for 9-series boards
            "8086:8cb1", Package()
            {

Or that 8086:8cb1 needs to be defined elsewhere in the AML file or somewhere else?

 

[RehabMan]

Meaning I should have that define like this?

Correct.

You should also check your Clover bootlog to be certain your SSDT is loading.
Check ioreg to see that the 'ports' property is as you expect.

 

[jmmusick]

Correct.

You should also check your Clover bootlog to be certain your SSDT is loading.
Check ioreg to see that the 'ports' property is as you expect.

Okay, so I'm really trying to work at this without asking too many questions. I know you've put an enormous amount of effort into documentation, so I appreciate that.

Based on what I'm seeing, Clover sees my .aml file. From what I understand, it should just load it as of newer versions. I have my folder setup attached in a pic. I thought I should be able to just put the aml file in patched without extracting my original files from my MB but that clearly isn't the case. In any event, I've extracted the files from my MB with Clover/F4. In patched, with just SSDT-8, it doesn't work. I do have Drop OEM enabled. If I drop the rest of the SSDT* files from origin into the patched folder, it boots. However, during boot, I'm still seeing that I've reached my port maximum. When looking at IOReg, I'm still not seeing any ports removed.

My guess is that I'm missing a patching step somewhere.

 

[jmmusick]

Read USB guide, post #1, "Problem Reporting".

Sure thing. Thank you!

 

[RehabMan]

Sure thing. Thank you!

Major problems with your ACPI/patched:
- ACPI/patched should not contain dynamic SSDTs
- If you're planning to provide patched SSDTs, you must use SortedOrder to enforce load order and you must use DropOem to eliminate the native SSDTs

SSDT-8.aml contains your RMCF for USBInjectAll.kext:
This is incorrect: "8086:8cb1"
Should be: "8086_8cb1"

I didn't look any further, as that one mistake is enough to make the data ignored by USBInjectAll.kext.

 

[jmmusick]

Major problems with your ACPI/patched:
- ACPI/patched should not contain dynamic SSDTs
- If you're planning to provide patched SSDTs, you must use SortedOrder to enforce load order and you must use DropOem to eliminate the native SSDTs

SSDT-8.aml contains your RMCF for USBInjectAll.kext:
This is incorrect: "8086:8cb1"
Should be: "8086_8cb1"

I didn't look any further, as that one mistake is enough to make the data ignored by USBInjectAll.kext.

So just to clarify, dynamic SSDTs are subsets of all of my SSDT files (SSDT-0-SSDT-7). Based on your guide, it sounds like I need to extract these to the DSL format for editing and then patch in the dynamic file (edited with your recommendation above). After that, I'll export back to AML and put that file in the patched folder. Then, I'll use the DropOEM flag.

With second bullet, it sounds like you're saying that there is an option to accomplish this without exporting all of my SSDT files, decompiling and then recompiling them with my patch. If that's the case, where should a dynamic SSDT file go? It sounds like if possible, that would be easier.