On Thu, Feb 06, 2014 at 11:30:29AM +0100, Hans Petter Selasky wrote: > On 02/04/14 20:10, Sarah Sharp wrote: > >And there's code in the xHCI driver to ignore the second successful > >event. See ep->last_td_was_short. Yes, this is a slight race > >condition, and we should wait for the successful event. However, we > >have not seen any issues with this race condition. > > Hi, > > Some comments from the side-line: > > I've observed some XHCI controllers sending special case events, > like IO-errors for ISOCHRONOUS endpoints, out of order. In not sure > if the XHCI specification is clear about this, or not, that when you > have bunch of TD's on an endpoint, you should not receive the > completion event for the next timeslot / TD, before receiving the > IO-error for the previous failed TRB/TD. I'm not sure what tests HW > guys are doing these days regarding XHCI. This has been observed > during driver development of FreeBSD's XHCI driver a long time ago, > and I though I'd mention it for you guys. Do you mean you get a missed service event, and then an event for some later TD? Or an event for that later TD, and then a missed service interval? Or maybe that you queue TD 1 and TD 2, and then receive events for TD 2 and then TD 1? What's the exact sequence of events here? ISTR the xHCI spec does say you could get out-of-order TDs when the host is actually an SR-IOV virtualized host. However, I had hoped that wouldn't happen when running on bare hardware. > FreeBSD's XHCI driver: http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/xhci.c?view=markup I can't look at that for licensing reasons, sorry. However, we can have a conversation about observed hardware behavior. :) 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
