On Tue, Mar 12, 2013 at 10:57:22AM +0100, jean-philippe francois wrote: > 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. Ok, I don't know what license your driver is under, so I can't legally look at the C snippet you sent me. > >>> 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. What do you mean by the "transfers 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. So that's a transfer error. You can't trust the actual_length field if you get a transfer error. > >>> 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. > >> > > > > It is a 0.96 host. : > > 0x960020 (CAPLENGTH AND HCIVERSION) All right, then my hypothesis wasn't correct. > > 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. That's not a short transfer you're seeing. You're seeing a protocol error, which usually means either: a bad cable, a bad connection between the device and host, or something is misconfigured in the xHCI driver. > > What is the meaning of "Endpoint 0x82 not halted, refusing to reset" > > The failed isochronous urb should happen on this endpoint. If your driver is calling into usb_reset_endpoint when the host endpoint hasn't stalled, you will get a mismatch between the toggle bit state in the xHCI host driver and the device. This is because currently, the xHCI driver refuses to send a Reset Endpoint command if the endpoint isn't actually halted. This is because the hardware will reject the command. The driver should issue a Configure Endpoint command instead. Are you calling into usb_reset_endpoint when the endpoint isn't halted? 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
