Hi,
Hmm, should have read the thread further before reply-ing to
Sarah's first response. Lets continue the discussion from here
as this part of the thread seems more focussed on the issue at hand.
On 06/04/2012 06:22 AM, Sarah Sharp wrote:
On Fri, May 25, 2012 at 09:47:53PM -0400, Alan Stern wrote:
On Fri, 25 May 2012, Hans de Goede wrote:
Judging by your description, there is a bug either in xhci-hcd or in
your xHCI hardware. What does "lspci -vv" show for the controller?
01:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast>TAbort-<TAbort-<MAbort->SERR-<PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fe600000 (64-bit, non-prefetchable) [size=8K]
Capabilities:<access denied>
Kernel driver in use: xhci_hcd
As far as I know, the NEC controllers have been very reliable.
But I don't believe this is hardware specific, I started investigating this
after a bug report from a user of my USB redirection code, that user
was seeing this with a thinkpad W510. I'll ask an lsusb -vv from him too,
just in case that model has the exact same hardware.
I'm thinking that maybe the issue is that the EREMOTEIO error gets generated
by the driver based on the SHORT_NOT_OK flag (or so I believe), not the hc
itself, could it be that the code doing that does not halt the ep, or halts
it too late?
Well, the EREMOTEIO error is _supposed_ to be generated by the
controller. That is, the hardware is supposed to recognize it as an
exceptional case and stop the endpoint queue.
The EREMOTEIO error does stop the endpoint queue, but it's my experience
that the upper layers never clear the halt on a bulk short packet, so
the xHCI driver just restarts the ring after moving the endpoint enqueue
pointer past the transfer that generated the short packet.
Otherwise we could have the case where multiple URBs are queued for a
bulk endpoint, a short packet stops the endpoint ring, the xHCI driver
never restarts the endpoint ring running, and then the queued URBs just
sit on the endpoint ring.
Right, as I already pointed out in my previous mail in this thread, it seems
that devio too assumes that the controller will clear the halt it self after
a short bulk in packet.
Would it be possible to first let the completion handler of the short packet
run before clearing the halt? And could it be this is what the EHCI code is
doing?
Regards,
Hans
--
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
