Hi,
-----Original message-----
> From:Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx
<mailto:sarah.a.sharp@xxxxxxxxxxxxxxx> >
> Sent: Saturday 15th February 2014 0:02
> To: Hans Petter Selasky <hans.petter.selasky@xxxxxxxxxxx
<mailto:hans.petter.selasky@xxxxxxxxxxx> >
> Cc: linux-usb@xxxxxxxxxxxxxxx <mailto:linux-usb@xxxxxxxxxxxxxxx>
> Subject: xHCI out of order events on BSD, was Re: xhci and other woes
>
> 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?
No, let me explain. I have a DVB USB adapter which would sometimes
overflow the wMaxPacket data transfer length, due to a design flaw or
so-called firmware/hardware bug. When that happened, I observed the
completions for the faulty transfers would be received out of order, and
would confuse the driver logic. This was not a missed service event
error. So actually:
ISOC TD frame1: OK
ISOC TD frame2: too long (IO-ERROR)
ISOC TD frame3: OK
ISOC TD frame4: OK
Resulted in:
ISOC TD EVENT complete frame1
ISOC TD EVENT complete frame3
ISOC TD EVENT complete frame4
Some delay:
ISOC TD EVENT complete frame2 w/error in status code.
Hardware "ASM1042 SuperSpeed USB Host Controller".
>
> 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.
No virtualization here.
>
>> FreeBSD's XHCI driver:
http://svnweb.freebsd.org/base/head/sys/dev/usb/controller/xhci.c?view=markup
<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.
That's fine. I don't read yours driver either BTW: There is something
called a dual BSD/GPL license
--HPS
--
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
