2013/3/12 jean-philippe francois <jp.francois@xxxxxxxxxx>: > 2013/3/12 jean-philippe francois <jp.francois@xxxxxxxxxx>: >> 2013/3/12 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>: >>> 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? >>> >> Kernel 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? >>> >> >> The completion handler for the submitteds urb is never called, so I would say >> no transfer is hapenning. After these error messages, nothing happens. >> The urb are not completed, so they are not restarted. >> When stopping the transfer, the HC dies. >> > > Sometimes the completion handler is called, but transfer are never > restarted anyway. > Attached is the interrupt routine code, and the relevant part of the log. > > Individual iso frame transfer are completed, actual_length field is > Ok, but status is -EPROTO. > > >>>> USB3 host is an asmedia ASM1042. Update : I have been able to test this on an intel XHCI, and it works fine, except for some difference in the treatment of short iso packet in the EHCI and XHCI path. On the ASM1042, it also work when the endpoint descriptor is set to 3x1000, bInterval = 2. But it does not with a iso endpoint descriptor of 3x1000, bInterval = 1. >>> >>> 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. >>> >> >> It is a 0.96 host. : >> 0x960020 (CAPLENGTH AND HCIVERSION) >> >>> 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. >>> >> >> I don't think it is the same issue here, because no transfer happens or is >> considered complete, and we are at the beginning of the frame, so there should >> be no short transfer. >> >> What is the meaning of "Endpoint 0x82 not halted, refusing to reset" >> The failed isochronous urb should happen on this endpoint. >> >> Thank you for your interest. >> >> Jean-Philippe François >>> 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
