On Mon, Jun 04, 2012 at 10:22:12AM -0400, Alan Stern wrote: > On Mon, 4 Jun 2012, Hans de Goede wrote: > > > >>> 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. > > The ring isn't supposed to be restarted until after the completion > handler (for the URB that got the short packet) returns. Doing it > earlier is a bug. Ok, let me take a look at that xHCI ring code and see if I can come up with a patch. I think if I let the completion handler run first, it should queue any cancellations for that ring, which will set the EP_HALT_PENDING flag for the xHCI virtual endpoint, and prevent the endpoint doorbell from being run when I unconditionally call xhci_ring_ep_doorbell() after the completion handler returns. Sarah Sharp -- 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
