Hi, It appears the commit e210c422b6fdd2dc123bedc588f399aefd8bf9de "xhci: don't finish a TD if we get a short transfer event mid TD" is causing transfers larger than 16kB to be unreliable. I ran into this testing the code from here: http://www.bitbabbler.org which with a recent enough kernel and libusb, will try to transfer up to 64kB from the device to the host in a single request. The USB side of things on that device is relatively uncomplicated, it is using an FTDI FT232H, in MPSSE mode, providing USB 2.0, and it all works fine if plugged into an EHCI port, or if using a kernel without e210c422b applied. If I limit transfers to be no larger than 16kB, then it also works as expected in an XHCI port with an unmodified build of Linus' current head (v4.4-rc7-76-g9c982e8), but transfers larger than that do not. I see an alternating cycle of a successful transfer, followed by two that will time out waiting in libusb (with a 5 second timeout set), before getting another successful transfer and the cycle repeating. I'd originally thought this was an error in backporting that patch to the distro kernel (reported here: https://bugs.debian.org/808953) but after some more testing it appears any kernel including that patch has this problem, and reverting it reliably fixes it again. I'm using libusb 1.0.19 from Debian Jessie, and have reproduced this on two different machines. Currently I'd expect any device doing a transfer larger than 16kB should be able to reproduce it too. Ben has reverted this for the next uploads of the distro kernel now, until we figure out what is really wrong there and get a fix into the mainline. I can run more tests and dig into this deeper if the reason for it isn't immediately obvious in hindsight. Cheers, Ron -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
