xhci: regression since hrev51536

[korli]

booting with a USB 3.0 32GB key, mouse and keyboard connected to usb 3 ports. Since I updated to hrev51536:

• keyboard stops working unexpectedly or at boot (it worked in the boot menu). I had for instance the tab key which stayed pressed.
• mouse behaves weirdly sometimes (when holding a button for instance)
• file cache had problems writing back to the disk (likely a timeout)

This setup didn't have these problems before (hrev51519). The recent commits probably made appear existing bugs in the driver, I don't know.

device Serial bus controller (USB controller, XHCI) [c|3|30]

vendor 8086: Intel Corporation device 8c31: 8 Series/C220 Series Chipset Family USB xHCI

listusb output:

413c:2107 /dev/bus/usb/0/2 "Dell Computer Corp." "Dell USB Entry Keyboard" ver. 0104
0461:4e22 /dev/bus/usb/0/4 "Primax Electronics, Ltd" "" ver. 0100
05dc:a83a /dev/bus/usb/0/5 "Lexar Media, Inc." "USB Flash Drive" ver. 1100
0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "XHCI RootHub" ver. 0300

I can't attach a meaningful syslog yet (full of port reset, etc). Request if needed.

[waddlesplash]

The "USB port reset spamming syslog" is an issue on my machine, too

[korli]

This is getting annoying, difficult to use a mouse or a keyboard that lock every 10-15 minutes.

[GregCrain]

Replying to korli:

This is getting annoying, difficult to use a mouse or a keyboard that lock every 10-15 minutes.

So before the change your mouse and keyboard worked perfectly on the USB3 ports? This surprises me.

Is anyone else working on this? As for me, I had never even looked at the USB driver up to a couple months ago. I was hoping there would be some more useful dialog with developers that have a deeper understanding of the design and history. Trying to understand what our driver doing, what is BSD driver doing, and what is really supposed to happen... it's all really slow going on my own.

Some things I'm trying to understand, and don't seem right:

-our driver doesn't handle or recover from a Stall.

-our driver doesn't seem to handle a partial transfer correctly..

-A USB3.0 hub doesn't work at all for me

-why does the hub driver try and set RO status bits? Is it for EHCI backward compatibility, or EHCI mapping in the XHCI? I don't know. This is my guess about the spamming.

-There is a transfer count that is supposed to increment and decrement. Once it hits its limit, our driver is dead. If several transfers are submitted, and somehow (partial transfers not handled?) doesn't decrement the count, or if an interrupt is lost somehow (Stall).. the driver stops. I'm not sure how to recover from this and what needs to change in the design. How to make this mechanism robust? This is happening a lot.

[korli]

Replying to Greg Crain:

So before the change your mouse and keyboard worked perfectly on the USB3 ports? This surprises me.

Yes it worked before with the setup I mentioned.

The driver was started by GSoC students (Jian Chiang then Akshay Jaggi), the latter said we had to do a complete overhaul of the USB stack to get XHCI working. As he disappeared, maybe because he wanted a contract that we failed to agree in time, I instead helped to get it working. Not enough for most people sadly. So, bugs there are, your mileage may vary..

[waddlesplash]

korli: "port change" spamming is all gone now, so can you please get a syslog?

[waddlesplash]

It seems that after ​db360a20648 & hrev52890, users are reporting that devices largely don't stall out anymore. So please re-test.

[waddlesplash]

Please retest after hrev52966; this fixed a nasty race condition which was likely related.

[waddlesplash]

#13772 which was almost certainly a duplicate of this has now been closed as fixed; and other users report on IRC that they no longer have any keyboard/mouse stalls, either. So closing this as fixed, too.