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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
