Bug#808953: xhci regression for large transfers (commit e210c422b)
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
Reply to: