Hi All, A while ago I submitted a patch with the following commit msg: "usb: xhci: Disable streams on Intel Cherrytrail controllers Using an UAS device (and thus USB-3 streams) on an Intel Cherrytrail device, results in the following error: xhci_hcd 0000:00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring xhci_hcd 0000:00:14.0: @00000000742f7120 00000000 00000000 06000000 02028000 Note that the completion code is COMP_STALLED and the buffer which was being processed last is set to NULL. Both are a problem here, the buffer being NULL is what directly results in this error, because that means we cannot find out which stream was stalled, so which ring the move to the next td / which urb to return to the device driver with a -EPIPE status. Even if we could figure out the active stream when this happened the COMP_STALLED itself is weird too as the UAS protocol does not define a stall response by the device. I've tried to fix this by simply doing a xhci_queue_reset_ep() on the endpoint, but that only makes things worse, going from waiting for the scsi layer to timeout (30 seconds) and the uas driver to do an usb-reset, to things not working at all." But today I found out the same happens on my skylake desktop but not on other systems, such as my skylake laptop... ? So first of all consider this a self-nack for my "usb: xhci: Disable streams on Intel Cherrytrail controllers" patch. I've spend some more time investigating this and I've noticed a few things: 1) The COMP_STALLED error with a buffer pointer of NULL hapens on both some skylake systems and all cht systems I've tested. 2) This only happens with a 2.5" uas capable usb enclosure with what I believe is a NEC usb to sata bridge. My only other uas capable device is an usb disk dock and the same ssd works fine on the troublesome machines when using that. But the NEC bridge enclosure works fine on many other machines too ... 3) IF I wait for the scsi subsys to timeout and for the uas driver to usb-reset the device then everything works fine, but the COMP_STALL errors happen quite frequent and this is SLOW so it seems what we really need is for the xhci driver to do something more sensible in the COMP_STALL with usb-3 bulk streams case. Mathias can you see if you can figure out how to deal properly with this error ? (Maybe ask the windows xhci driver people?) Regards, Hans -- 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
