I'm debugging a problem with the "xum1541" usb adapter (used to interface with legacy cbm floppy drives), which doesn't work correctly when plugged into some usb ports but works fine in others. The symptom of failure is that the host command only works the first time after the device has been plugged in. This is what I found so far: The device mostly uses bulk transfers for communication. After every start, the host program issues a "set configuration" command (even though the device only has a single configuration). On receiving the "set configuration" message, the firmware of the xum1541 device does an endpoint reset including a reset of the data toggles. The problem is, that my host computer only seems to reset its data toggles when the device is plugged into a usb port that as per syslog uses the "ehci-pci" driver, while it does not in ports using the "xhci_hcd" driver. That's why the data toggles get out of sync when the device is plugged into a port handled by the "xhci_hcd" driver and therefore stops working. For now I try to work around this issue by avoiding the "set configuration" call altogether, but I'm still curious what the correct behaviour is. The notion of a "set configuration" call that doesn't really change the configuration triggering a "lightweight reset" seems to be common, but I'm not sure if there's consensus what the reset should include. So I'm not sure which behaviour (to reset the data toggles or not) is correct, but I think at least the linux kernel should behave consistently regardless of the usb driver / port used? Is resetting the data toggles even handled by the driver (or by the hardware)? There are reports of what seems to be the same problem (device not working after the first command but only when using an usb 3 port) on windows as well. I personally can't reproduce that, but that's no big surprise because the current libusb on windows doesn't actually send the "set configuration" message to the device. It might do using a different libusb version and/or windows usb driver, though. This is what lspci reports about the usb controllers on my machine: > lspci | grep -i usb 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04) > lsusb | grep -i hub Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub The device does not work correctly when connected to bus 2, but it does when on bus 3. The host is running arch linux with currently linux 5.8.1, but the problem existed at least in the last few kernel versions. The host program is using libusb 1.0.23. Let me know if there's anything I can do to help debug this. Thanks! Martin
