Re: [Libusbx-devel] usbdevfs: BULK_CONTINUATION flag does not work with XHCI controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 25, 2012 at 09:47:53PM -0400, Alan Stern wrote:
> On Fri, 25 May 2012, Hans de Goede wrote:
> 
> > > Judging by your description, there is a bug either in xhci-hcd or in
> > > your xHCI hardware.  What does "lspci -vv" show for the controller?
> > 
> > 01:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI])
> >          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> >          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> >          Latency: 0, Cache Line Size: 64 bytes
> >          Interrupt: pin A routed to IRQ 16
> >          Region 0: Memory at fe600000 (64-bit, non-prefetchable) [size=8K]
> >          Capabilities: <access denied>
> >          Kernel driver in use: xhci_hcd
> 
> As far as I know, the NEC controllers have been very reliable.
> 
> > But I don't believe this is hardware specific, I started investigating this
> > after a bug report from a user of my USB redirection code, that user
> > was seeing this with a thinkpad W510. I'll ask an lsusb -vv from him too,
> > just in case that model has the exact same hardware.
> > 
> > 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.

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.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux