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

["Tanya Brokhman" <tlinder-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]

Hi Sarah

> 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?

Np. I've already overcame this issue but I'll roll back and send you the
dmesg output. When I tried enabling this flag the dmesg was swamped with
xhci messages and the messages I was looking for weren't there already. 
I read that in order to increase the dmesg buffer size one needs to update
the #define of LOG_BUF_LEN in linux/kernel/printk.c. I haven't tried that
yet. Is this correct?
Do you need the LECroy recording as well?

> 
> 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
> 

We're using NEC but I'm not sure where to retrieve the version from. The
line you mentioned isn't present in the dmesg output and I found nothing
similar written on the chip either.

Best regards,
Tanya Brokhman
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum





--
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