Contribute
Register

USB port limit patch for 14.1, 14.2, 14.3, 14.5,14.6

It looks as though your Asus motherboard headers are: 2x USB 3.1G1 ports (4x virtual) & 2x USB 2.0 ports (2x) along with that front-panel connector with 1x USB3.1G2 ports (2x virtual) = 8

View attachment 395057


Counting back-panel ports and totalling the 'virtual' = 12.

8+12 is the standard 20.

However I'm pretty sure those "extra" ports, and I'm still surprised at 6x virtual, are related to the built-in back-panel wireless/bluetooth. The graphic shows wifi as M.2 though. So these ports show in IOReg but are not actually user-accessible, so to speak. Which is fair enough.

Interestingly the total number of USB ports supported by the Intel Z390 chipset is:

10 x USB 3.1 Ports
- Up to 6 USB 3.1 Gen 2
- Up to 10 USB 3.1 Gen 1
14 x USB 2.0 Ports

... for 34 virtual ports.

It would be good to know more because clearly your output shows 26. :thumbup:

:)

I booted into Windows 10 and used the USBTreeView utility to explore my USB ports. I believe I correctly identified 14 physical ports but the enumerator lists 2 more. They could be used for any number of things but I wasn't able to get to the bottom of it.

The relevant part is that it also enumerated 26 ports so the results are identical to what OSX enumerated. This pretty much settles the issue for me but I understand you may have more questions. To answer those and many more, please find a text and XML version of the report it produced.

Let me know what you find out, enquiring minds want to know!
 

Attachments

  • UsbTreeView_report_BIGRED.txt
    155.8 KB · Views: 370
  • UsbTreeView_report_BIGRED.xml.zip
    10.3 KB · Views: 95
I booted into Windows 10 and used the USBTreeView utility to explore my USB ports. I believe I correctly identified 14 physical ports but the enumerator lists 2 more. They could be used for any number of things but I wasn't able to get to the bottom of it.

The relevant part is that it also enumerated 26 ports so the results are identical to what OSX enumerated. This pretty much settles the issue for me but I understand you may have more questions. To answer those and many more, please find a text and XML version of the report it produced.

Let me know what you find out, enquiring minds want to know!

Thanks for the output from UsbTreeView - interesting. :thumbup:

By the way, I didn't doubt for a minute that you had 26-ports showing in your IORegEx etc. That's clear from the screen-grabs.

The point of this thread was the available Port-Limit Removal patches and the changes needed for OS updates. By using patches you apparently found more ports than could easily be accounted for. That needed looking into.

For example the list shows you have 4x USB Type-C sockets. So has your board got more than the 1x which can be seen on the back panel?

The annoying fact that these patches are no-longer reliable across all motherboards/chipsets in Mojave is reason enough to do the 15-port configuration work. By going with @RehabMan 's main guide you can properly discover them all and then exclude unnecessary ones via the boot command-line if you'd rather pick and choose.

:)
 
Last edited:
Thanks for the output from UsbTreeView - interesting. :thumbup:

By the way, I didn't doubt for a minute that you had 26-ports showing in your IORegEx etc. That's clear from the screen-grabs.

The point of this thread was the available Port-Limit Removal patches and the changes needed for OS updates. By using patches you apparently found more ports than could easily be accounted for. That needed looking into.

For example the list shows you have 4x USB Type-C sockets. So has your board got more than the 1x which can be seen on the back panel?

The annoying fact that these patches are no-longer reliable across all motherboards/chipsets in Mojave is reason enough to do the 15-port configuration work. By going with @RehabMan 's main guide you can properly discover them all and then exclude unnecessary ones via the boot command-line if you'd rather pick and choose.

:)

Apparently one of the mid-board ports can be USB-C.

Just so you know, I did read Rehabman's guide and did have a custom SSDT. The 15 port limit meant I had to sacrifice ports and functionality, which is why I found that the PLRP such an elegant solution. It also happened to work perfectly in my configuration and the Windows tests proved it.

I was also surprised to find that someone with an older Gigabyte MB used my guide and experienced a perfect install. And herein lies the crux of the matter. If we can eliminate as many kexts as possible and use a generic methodology, we can have a pretty universal and functional install.

The myth buster in me wonders if the community applies lessons carried over from previous versions. A good example is the whole kext installation location debate, one which drove me to consult a WEG developer and a few others to reach a conclusion. Another example is the assertion that my CNVi slot would never recognize my DW1560. Ignorance was bliss because I installed the card with the expectation that it to work right out of the box with full Continuity support, which it did!

My point is that some of the fundamental assertions that drive current thinking may no longer be valid, the trick is figuring each one.

As to you driving me to justify my answers, that was fun and I learned plenty doing it. Please don’t stop questioning me, I never took offense and enjoyed you leading me into knowledge. You have an extremely non-challenging way of asking questions that drive knowledge. It's a skill not many people have.

In the end, it helped me get the understanding I needed to test @ydeng assertion.
 
Last edited:
@UtterDisbelief So what does a PLRP patch entail? Are you just changing values in the kext to remove the port limit?

Coming from a time, long, long ago and in what feels like another galaxy, I'd call it Peek'ing and Poke'ing. When it was a perfectly innocent term. Machine Code is another.

Good to talk :thumbup:
 
Coming from a time, long, long ago and in what feels like another galaxy, I'd call it Peek'ing and Poke'ing. When it was a perfectly innocent term. Machine Code is another.

Good to talk :thumbup:

I just posted the new PLRP for 10.14.4 so we can resume our adventure in that thread.
 
Apparently one of the mid-board ports can be USB-C.

Just so you know, I did read Rehabman's guide and did have a custom SSDT. The 15 port limit meant I had to sacrifice ports and functionality, which is why I found that the PLRP such an elegant solution. It also happened to work perfectly in my configuration and the Windows tests proved it.

I was also surprised to find that someone with an older Gigabyte MB used my guide and experienced a perfect install. And herein lies the crux of the matter. If we can eliminate as many kexts as possible and use a generic methodology, we can have a pretty universal and functional install.

The myth buster in me wonders if the community applies lessons carried over from previous versions. A good example is the whole kext installation location debate, one which drove me to consult a WEG developer and a few others to reach a conclusion. Another example is the assertion that my CNVi slot would never recognize my DW1560. Ignorance was bliss because I installed the card with the expectation that it to work right out of the box with full Continuity support, which it did!

My point is that some of the fundamental assertions that drive current thinking may no longer be valid, the trick is figuring each one.

As to you driving me to justify my answers, that was fun and I learned plenty doing it. Please don’t stop questioning me, I never took offense and enjoyed you leading me into knowledge. You have an extremely non-challenging way of asking questions that drive knowledge. It's a skill not many people have.

In the end, it helped me get the understanding I needed to test @ydeng assertion.

Just back from a 'fun' 10.14.4 upgrade...

Okay, just a thought or two more for you about those pesky ports.

The only motherboard header that might be wired as a pseudo-Type-C port is that funny front-panel connector. I can't tell from the graphic how many pins it has but my guess would be, if it has the full roster of 24, then it could function as just 1x Type-C.

But that only bumps up the total to 2x Type-C ports. And they are all SS, not HS so that's not the origin.

My remaining worry with PLRP methodology is still that, in your case, why are there 4x Type-C ports showing - SS01/SS02/SS05/SS06?

So is this a function of the PLRP or something else? If you staunchly promote a no-restriction approach to USB ports, okay, that's fine, but you should still want to know where they are. Not knowing begs the question, how can you tell if they're configured correctly and won't fry something sensitive, for example?

:crazy:
 
@UtterDisbelief I am not resigning to not knowing and frankly, I think they are just naming errors. I am looking for you to tell me how to figure it out. I do have 2 semi-related questions for you:

1) What is the easiest way to decompile a DSDT? I followed this guide but the last step doesn't work. It keeps reporting:

Code:
Could not open input file: DSDT.aml
Could not get ACPI tables from DSDT.aml, AE_NOT_EXIST

2) Also, a closer look at my USB from the windows side shows that my keyboard and mouse have "Child USBs" and windows installs 4 usb devices for the mouse and keyboard. Do hubs get enumerated as well? Are you supposed to disconnect them during enumeration?
 
Back
Top