Re: Isochronous transfer error on USB3

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

 



On Mon, Mar 11, 2013 at 01:21:48PM +0100, jean-philippe francois wrote:
> Hi,
> 
> The company I work for is doing USB cameras, for which I wrote the
> drivers (out of tree).

Kernel driver or userspace driver?

> Raw camera data are transferred using isochronous transfer, which work
> fine when used on USB2 EHCI.
> 
> However when plugging the camera on an USB3 port, xhci spits the
> following messages on URB submission :
> 
> [ 1704.989785] xhci_hcd 0000:01:00.0: ERROR Transfer event TRB DMA ptr
> not part of current TD

Does the device work properly, despite the error messages?  I see that
there are transfer errors in the log file, along with those messages.
Are those expected?

> USB3 host  is an asmedia ASM1042.

Do you know if this is a 1.0 xHCI host?  E.g. when you enable
CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING, do you see lines
like this during driver initialization:

CAPLENGTH AND HCIVERSION 0x1000080:

If you see that line start with 0x100, it's a 1.0 xHCI host.  If starts
with 0x096, it's a 0.96 host; 0x095 would be a 0.95 host.

I ask because I have a todo list entry to fix short packet handling on
xHCI 1.0 hosts:

"On Intel Lynx Point xHCI, when you plug in a HS USB webcam, the log
will fill with the error message:

ERROR Transfer event TRB DMA ptr not part of current TD

However, the video looks fine, and there is no impact on the driver
behavior.

This is caused by a change between the xHCI 0.96 and the xHCI 1.0 spec.
The change describes in section 4.10.1.1 how the xHCI host controller
should handle short transfers that happen on a TD comprised of more than
one TRB chained together. The 0.96 spec says that the host will only
send one event with a short completion code for the TD. The 1.0 spec
says if the short packet happened on a TRB that wasn't the last TRB in
the TD, then we will get two events with short completions (one for the
short TRB and one for the last TRB with the IOC flag set). The 1.0 spec
says that the xHCI driver shall not consider the TD to be done until the
second event is received.

The current xHCI driver behavior finishes the TD when it receives the
first short event. Then when it receives the second event, it prints the
warning message.

This also appeared under the xHCI 1.0 host in Intel Panther Point xHCI,
but it was mistaken for a known hardware bug, the spurious successful
event bug. The work-around that was put into the driver masks this xHCI
driver bug.

Impact on the driver is minimal for this bug.

The easy fix is just to change the XHCI_SPURIOUS_SUCCESS quirk to be
applied for all 1.0 xHCI hosts. However, that doesn't solve the race
condition that exists when the endpoint is stopped before the second
event TRB is received.

The harder fix is to either add an event data TRB after the chained TD
(and stop using ISP and IOC flags), or make the xHCI ring handling code
wait for the second event completion for xHCI 1.0 hosts."

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