Limited device count on Intel USB 3.0 eXtensible host controller/C216?

Just got notified by my system that I'm attaching more than the allowed devices to the Intel USB 3.0 eXtensible host controller/C216. First I tried to connect through some hubs - than directly to the notebook in case the USB hub chain is too long ;-) I was still unlucky. I do not want to remove other devices!

Upgrading the driver to the latest found on Intel page did not change anything.

Additonally it seems that all external ports on the Asus N56VZ are connected to this controller - even there is one totaly unused controller inside (what is the reason that this one is not forwarded to the outside world?).

Since I'm running a USB docking station with a lot of devices connected it might be that I just crossed the 127 device limit, which I could hardly believe. USBDeview just shows up 36 connected devices in total (none related controller included).

Since I could not find any information on the web about it, my last step was to contact Intel. Let's see what they will reply.

Ah... and the notification message can be found in the localization part of the driver :-)
Another thought is that the connected USB hubs reserve slots even they are currently not in use. USBView tells that there 15 connected devices (1 not working due to the limits) and 16 free slots. So this is also not the case. Maybe they limit the total number of endpoints?

Playing with two devices that have a different count of endpoints confirms that :( A device can have upto 32 endpoints. This number is close to the free+used slots which I found on USBView. Maybe it has todo something with that... (like the connected devices are counted as endpoints for the root hub)

Next update: What a mess!!! I uninstalled this Intel driver, so it showed up as unknown device in device manager. I easily could extend the USB ports to 34. I could use minimum 20 USB devices now. More I could not test, since not enough devices laying around. This means it is a software limitation by the Intel driver. And also very interesting (this is what I mean with mess): It was now using the USB ports which formerly I thought are not routed to the outside of the notebook. On device manager and USBView my devices werde definately shown on the other USB hub, even after reinstalling the Intel drivers. I think next startup they will be back to the problematic Intel USB hub.

Conclusion is, that this Intel driver provides a virtual USB hub - maybe like advised by the driver name (eXtensible) it just provides extra features to USB. Need to read documentation? :-)

Keyword: vendor limitation!
Next step: Change it to have more than 15/16 devices.

Solution for me: I manually installed the desktop drivers for C220 (hub+xhci, not the PCI drivers in HCSwitch folder) instead of the recommended C216 ones. Looks like I can use 2 more devices with that, which is currently enough for me.I also tried to patch the drivers, but w/o luck so far. iusb3mon.exe seems to be there only for user feedback (tray balloons). (It's possible to set a timeout and a debugging flag in registry, but this did not change anything for me)

Conclusion: Too much time wasted; Should be documented somewhere!

Next update... it's getting annoying. The root hub was replaced by old drivers automatically and new devices were not enumerated correctly. I installed the version again that comes from Asus. The latest driver from Intel seems to be not stable during installation ("Does not meet system requirements", Aborts installation in middle, brings bluescreen during install and startup). Even after removing all components manually, so should be now leftovers from my previous tries :(

An employee of Intel replied:

Ivy Bridge xHCI hosts are limited to 64 endpoint rings, including control endpoint rings.  I can see that limit easily being hit by 15-18 devices.

Intel support sent me a link to the datasheet with more than 500 pages. Actually could not easily find anything mentioned about the limits inside.

Asus replied me with a new driver (not latest like from Intel page). Same device limit :-/

Update 25.09.2013:
I had a few mail contacts with ASUS. They are quite friendly and dived a bit into the problem (asking their technicals and contacted Intel). Intel replied them with a screenshot of USB deview and told that not each device has only one endpoint and it's an endpoint limit. The ASUS translation was not completly correct, but luckily they included the original answer. I asked ASUS to tell me the limit of endpoints. No reply since 1 month :(

Also I counted the endpoints on my system and found out that more than 86 endpoints are connected to the Intel 3.0 Host. The exact number i was not able to figure out because on viewing my Displaylink (is another story that I could tell :)) device Deview just crashes. Additonally there are 10 endpoints connected to the internal hosts.

I also tried to disassemble the driver, but since I do not know the exact count it's quite difficult to find the comparation. Additionally the error strings are all in one function (quite a mess) - probably generated by the compiler.

So far I decided to disconnect devices and connect other devices. Ugly task :)

[rev] a small ARM riddle

Today I just looked over some ARM binary and found this interesting piece:

47 78          BX      PC
46 C0          NOP
E5 5E C0 01    LDRB    R12, [LR, #-1]
E1 53 00 0C    CMP     R3, R12
37 DE 30 03    LDRCCB  R3, [LR, R3]
27 DE 30 0C    LDRCSB  R3, [LR, R12]
E0 8E C0 83    ADD     R12, LR, R3, LSL#1
E1 2F FF 1C    BX      R12

So, let's start my new blog with a small riddle ;-)
I'll soon provide a sample calling this method and later a full explanation.

Update 1:
The function is called from thumb mode like this

0xB8: FX XX FX XX    BL      func
0xBC: 06 04 16 1B+   DCB 6, 4, 0x16, 0x1B, 0x20, 0x57, 0x5C, 0x61

Update 2:
Since I'm frustrated with DisplayLink and Intel... let's use the time to explain.
BX PC changes the mode from thumb to arm. Inside LR we have the next address that should be executed on a return. This is still in thumb mode (which is offset+1). So the LDRB will load 0x06 to R12. What is not visible, is that R3 is loaded with a value. In the next instruction this value is compared with the currently loaded byte. LDRCCB (UAL instruction) will load LR + R3 to R3 if R3 is lower than R12. Else it will use the R12 value. At the end it will jump to R3 << 1 offset from LR. So we have a jumptable (switch). The first byte after the call (BL) tells us the entries. The next one is the default branch. The left shift by two is done so it will always go to valid thumb mode instructions again.

If you have a valid IDA license you can follow the following instrcutions :-)

1. Rename the switch function to switch or whatever
2. Right click and set it will not return. This prevents parsing of the switch byte table.
3. Place your cursor on a BL switch and choose Edit -> Other -> Specify switch idiom
4. Address of jump table set to 0xBC (modify to meet the count entry in your case)
5. Number of elements to the first byte + 2 (8)
6. Size of table element to 1 (one byte for one switch case)
7. Element shift count to 1, this is the LSL#1
8. Input register to R3 (does not really matter)
9. First(lowest) input value to -1 (because of the count at the beginning, so it will align switch cases correctly)

Et voilà :-) Now it's time to write a script that will do this automatically for all switch()es...