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. Sarah knows the answers; she's the xhci-hcd maintainer. Anything I said about it would just be speculation. 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
