Re: UAS gadget driver & UAS host driver [was: Re: [RFC/PATCH 0/4] UASP device driver]

[Sarah Sharp <sarah.a.sharp-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]

On Mon, Feb 21, 2011 at 08:48:01AM +0200, Tanya Brokhman wrote:
> Hello Sarah, Matthew
> 
> We're almost done with our internal testing (using the MSDVT tool we
> purchased from MCCI and the UT we developed) so our main concentration right
> now is on the UAS host which isn't working for us very well.
> 
> Attached is the dmesg snippet from the UAS host. (I've added a few dbg
> printk while debugging)
> The SCSI command sequence that occurs after enumeration is INQUERY, TEST
> UNIT READY, READ CAPACITY, MODE SENSE. The first 3 finish correctly but
> after issuing MODE SENSE command I observe 2 strange warnings:
> 
> [ 4335.771653] xhci_hcd 0000:01:00.0: WARN: babble error on endpoint
> [ 4335.771657] usb 9-1: ep 0x81 - asked for 4 bytes, 4 bytes untransferred
> [ 4335.771771] xhci_hcd 0000:01:00.0: WARN Set TR Deq Ptr cmd invalid
> because of stream ID configuration

That particular error is from the host side.  It means the xHCI driver
tried to move the ring dequeue pointer past the last part of your
command (probably the status phase), and the host refused to do so,
because that was the "active" stream ID.  Can you please send me the
full dmesg for the stalled request with CONFIG_USB_XHCI_HCD_DEBUGGING
turned on?

I think it's worth rolling back your firmware for this because I really
need to test this corner case.  I think it may be an unhandled corner
case that I've been warning Intel's xHCI spec architect about.  There
seems to be no way to modify the active stream's rings for cases like
these where the transfer stalls.

Which host controller are you running under?  If it's an NEC host
controller, please send me the line that looks something like this:

NEC firmware version xx.xx

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html