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. Here is the relevant part of the kerneldoc for usb_unlink_urb(): * Host Controller Drivers (HCDs) place all the URBs for a particular * endpoint in a queue. Normally the queue advances as the controller * hardware processes each request. But when an URB terminates with an * error its queue generally stops (see below), at least until that URB's * completion routine returns. It is guaranteed that a stopped queue * will not restart until all its unlinked URBs have been fully retired, * with their completion routines run, even if that's not until some time * after the original completion handler returns. The same behavior and * guarantee apply when an URB terminates because it was unlinked. * * Bulk and interrupt endpoint queues are guaranteed to stop whenever an * URB terminates with any sort of error, including -ECONNRESET, -ENOENT, * and -EREMOTEIO. Control endpoint queues behave the same way except * that they are not guaranteed to stop for -EREMOTEIO errors. Queues * for isochronous endpoints are treated differently, because they must * advance at fixed rates. Such queues do not stop when an URB * encounters an error or is unlinked. An unlinked isochronous URB may * leave a gap in the stream of packets; it is undefined whether such * gaps can be filled in. * * Note that early termination of an URB because a short packet was * received will generate a -EREMOTEIO error if and only if the * URB_SHORT_NOT_OK flag is set. By setting this flag, USB device * drivers can build deep queues for large or complex bulk transfers * and clean them up reliably after any sort of aborted transfer by * unlinking all pending URBs at the first fault. * * When a control URB terminates with an error other than -EREMOTEIO, it * is quite likely that the status stage of the transfer will not take * place. > > 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? Yes and yes. Alan Stern -- 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
