Thanks for your report!

Your output shows only USB 2 usage.
Can you please try if it works in native USB 3 mode?
You will see a lot more hubs though, total hub count should be 10 (5USB2+5USB3).
Also, turning power off might get really tricky if your hub does not advertise unique container ids.

This is first time I see 5x daisy chaining. Most I've seen before was 3x for 10 port hubs.
They did 4*5 - 4 (lost to daisy chaining) = 16.

In a USB3 port (I only put it in a USB2 port on the pi for simplicity as I am just using it for power control)

Current status for hub 2-2.4 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 1: 02a0 power 5gbps Rx.Detect
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 02a0 power 5gbps Rx.Detect
  Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 2-2.3.4 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 1: 02a0 power 5gbps Rx.Detect
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 02a0 power 5gbps Rx.Detect
  Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 2-2.3.3 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 1: 02a0 power 5gbps Rx.Detect
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 02a0 power 5gbps Rx.Detect
  Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 2-2.3 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 1: 02a0 power 5gbps Rx.Detect
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 0263 power 5gbps U3 enable connect [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 0263 power 5gbps U3 enable connect [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
Current status for hub 2-2 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 1: 02a0 power 5gbps Rx.Detect
  Port 2: 02a0 power 5gbps Rx.Detect
  Port 3: 0263 power 5gbps U3 enable connect [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 0263 power 5gbps U3 enable connect [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
Current status for hub 1-1.2.4 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 1: 0100 power
  Port 2: 0100 power
  Port 3: 0100 power
  Port 4: 0100 power
Current status for hub 1-1.2.3.4 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 1: 0100 power
  Port 2: 0100 power
  Port 3: 0100 power
  Port 4: 0100 power
Current status for hub 1-1.2.3.3 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 1: 0100 power
  Port 2: 0100 power
  Port 3: 0100 power
  Port 4: 0100 power
Current status for hub 1-1.2.3 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 1: 0100 power
  Port 2: 0100 power
  Port 3: 0507 power highspeed suspend enable connect [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 4: 0507 power highspeed suspend enable connect [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
Current status for hub 1-1.2 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 1: 0100 power
  Port 2: 0100 power
  Port 3: 0507 power highspeed suspend enable connect [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 4: 0507 power highspeed suspend enable connect [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]

I had mapped out the ports (above), but have tried a few things in this USB3 mode and different ports are turning off than I would guess (but they are turning off).

Here are two attempts turning things off based on this connection but this affected a different port to my guess and I didn't have much time to investigate. If there is something you would like me to check out let me know!

pi@pi-sdr:~ $ uhubctl -a on -l 1-1.2.3.3 -p 4
Current status for hub 2-2.4 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 02a0 power 5gbps Rx.Detect
Sent power on request
New status for hub 2-2.4 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 1-1.2.3.3 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 4: 0000 off
Sent power on request
New status for hub 1-1.2.3.3 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 4: 0100 power
pi@pi-sdr:~ $ uhubctl -a off -l 2-2.3.3 -p 4
Current status for hub 2-2.4 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 02a0 power 5gbps Rx.Detect
Sent power off request
New status for hub 2-2.4 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 00a0 5gbps Rx.Detect
Current status for hub 2-2.3.3 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 02a0 power 5gbps Rx.Detect
Sent power off request
New status for hub 2-2.3.3 [0bda:0411 Generic 4-Port USB 3.1 Hub, USB 3.20, 4 ports]
  Port 4: 00a0 5gbps Rx.Detect
Current status for hub 1-1.2.4 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 4: 0100 power
Sent power off request
New status for hub 1-1.2.4 [0bda:5411 Generic 4-Port USB 2.1 Hub, USB 2.10, 4 ports]
  Port 4: 0000 off

Since this seems to be a smaller vendor, I'd be happy to reach out to them and explain what they need to change for future hardware revisions if you could summarise it for me? Worth a shot, anyway!

Sure. Per USB 3 spec, each hub in USB2/USB3 virtual pair must have bos container id, which must match for the pair, but be globally unique otherwise. E.g. if you run sudo lsusb -v, look for container id, it is the same for all 10 hubs. In proper case, we should see 5 different IDs, and they should match for each pair that represent physically the same ports.

Reply from the hub support team enclosed, I will also post my reply - in which I will direct them to this issue because I am not qualified to answer all of their questions!

1. What does "bos container ID" mean?

2. Did you test it without any devices plugged in? If you had some devices plugged in the 16 port hub, were they all USB 3.0 devices? or USB 2.0 devices?

3. Since you did not inform us which system version you were using, did you check the FAQ "Raspberry Pi turns power off on all ports, not just the one I specified" to find out the solution regarding your raspberry pi system?

4. We are not sure if it is your raspberry system limits. Have you ever try another USB hub with fewer ports, 7 port, or 10 port USB hub? You are more than welcome to test our product line (ROSONWAY hubs or RSHTECH USB Hubs)

5.Can you tell us the detailed steps and results of the test? So that our solution providers can simultaneously test and compare. Attached the software we downloaded from the website, please help to check if it is complete.

My response:

Thank you for looking into this issue for me.
I have added your response and this to the github issue for this #276
Perhaps you can direct your team there as hopefully you can engage with the author of the software who is more knowledgeable that I.

1. I believe this is an identifier for each hub. Since the RSH-16 is made up from 5 daisy-chained 4 port hubs internally the identities of each should be unique (but the same for the USB2 vs USB3 containers). I hope the author of uhubctl can confirm the specification for you.
2. My test environment is with a number of USB-powered devices. I am toggling the power successfully when used as a USB2 device. The issue raised relates to when the hub is in a USB3 port and it doesn’t matter what the devices are that are in each socket.
3. I am using a raspberry pi 4, and am not affected by this problem. This isn’t a raspberry pi issue and would present on any linux hardware.
4. I do not think that it is an issue with the number of ports, but rather than internal configuration of the device. I suspect you will find the same problem on your 7 and 10 port hubs – I would be happy to test this for you but I think you can probably reproduce the issue without having to ship me any hardware.
5. I installed the software from the raspberry pi Raspbian distribution using ‘sudo apt install uhubctl’ – I think it is probably in most ubuntu related distributions which will prevent you needing to build from source. You can see the container details using the linux built in lsusb -v as well as through uhubctl.

The RSHTech support team have come back, would appreciate some assistance with any reply since there is a difference in view of the specifications (ie whether each container id should be different in this kind of compound device).
If this is factually correct the strategy should be to identify the top of tree matches and navigate to the same position in the device tree?

Here below is the reply from our IC maker:

1. The hub IC complies with USB IF certification and has TID from related associations.
2. The Container ID of the same hub should be the same. If 5 same hub ICs are made into the same product, the Container ID should also be the same to let the host know that they belong to the same product.
3. If you request that each container ID should be different, we can modify the container ID of the hub through F/W, but it's better not to modify it casually because we are not sure whether there will be other side effects.

Per USB 3.2 specification at https://www.usb.org/document-library/usb-32-specification-released-september-22-2017-and-ecns:

9.6.2.3 Container ID

This section defines the device-level Container ID descriptor which shall be implemented by
all USB hubs, and is optional for other devices. If this descriptor is provided when operating
in one mode, it shall be provided when operating in any mode. This descriptor may be used
by a host in order to identify a unique device instance across all operating modes.

There is nothing in a sepc talking about assigning the same container id to multiple USB chips inside daisy chained hub. But, there is a requirement that unique container ID be provided by the same physical device whether it operates in USB 3 or USB 2 mode.

I understand that vendor does not want to change device behavior and to do any firmware changes, and I am willing to provide hacks on uhubctl side to make it work properly without workarounds.
However, it is very difficult to do it without having physical access to these devices. Would it be possible to request a sample from Rosonway? I will return it back once solution is implemented.
@jfberry

Correlation issue should be fixed by 44f963d in #288, @jfberry.

I'm trying to use this hub on a Pi4 hoping to connect 16 externally powered hard drives to it. When its plugged into a USB3 port on the Pi4, I could only plug in 6 HDs before the OS complained xHCI max of 32 was reached and unable to allocate new ID. If I plug the hub into a USB2 port, I could plug in 12 HDs with a keyboard also plugged in to a USB2 port, and 13 HDs if I unplug that keyboard and free up a USB2 port (and ssh into the Pi4). I reached out to RSHtech support and they referred me to this page. Is what I'm trying to do possible on a Pi4?

That could be linux kernel bug, just judging by the error message you are observing regarding 32 max for xhci - per USB standard maximum number of devices on a given USB bus has a limit of 127. I'm not sure why linux is limiting it for xhci (aka USB 3).

I would recommend trying to attach this hub to other Linux host or different is like Mac or FreeBSD, and see if you could connect all of your 16 drives on USB 3.

This is from a Ubuntu developer on xHCI:

The 32 devices is an xhci limitation. No way around it (/me thinks).
xhci only supports up to 96 endpoints and each USB device consumes at
least 3 endpoints...

And then you have a tiered structure with hubs so the number of
attachable 'real' devices is reduced even further.

If this is correct then what is the point of having a 16 port USB3 data hub? And this problem presumably would be present on Windows as well.

I tried connecting this hub to a USB2 port on the Pi4, and could plug in a total of 13 hard drives (after I unplugged the keyboard from the other USB2 port, otherwise the max would have been 12). Ubuntu complains xHCI limit of 32 was reached and unable to allocate new ID to the additional drive.

@jayhohoho2019,

1. This post suggests that 96 xhci endpoint limit is a hardware limitation of your computer host controller: https://www.reddit.com/r/oculus/comments/7h6mqu/what_not_enough_usb_controller_resources_actually.
   In other words, it is a problem with host computer hardware, not necessarily with USB hub.
2. This issue has nothing to do with uhubctl, which is what this repository is all about :-) In other words, this is not really good place to discuss it. I recommend reaching out to Linux USB mailing list, these folks might help. Or turn to reddit I guess.

@jayhohoho2019, this article explains xhci limits pretty well: https://acroname.com/blog/how-many-usb-devices-can-i-connect
Long story short, don't blame USB hub vendors or USB standand in general, blame USB host controller vendors.

I got all 16 ports recognized by plugging it into the usbC port. A few things needed to happen in advance for that to work. 1. Supply power through PoE (or GPIO on the Pi4). 2. Switch the USB C port to host mode, and using the dwc2 driver. 3. Reboot Pi4. It's down to USB2.0 speed though but it doesn't have the same limit as xHCI.

There is another batch of RSH-A16 is currently sold in some places, it may not work 100% - more in issue #411.
Original RSH-A16 works well for me