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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libusbx-devel
