> No, that trace did not show any failure. Did you see the corresponding > error messages in the kernel log while you were collecting the trace? > Maybe you can try again. This xhci debug spew might be helpful. ffff800073097780 342993897 S Bi:8:003:1[ 341.533219] xhci-hcd xhci-hcd.1.auto: Babble error for slot 3 ep 2 on endpoint [ 341.541655] xhci-hcd xhci-hcd.1.auto: Cleaning up stalled endpoint ring [ 341.548262] xhci-hcd xhci-hcd.1.auto: Finding endpoint context [ 341.554087] xhci-hcd xhci-hcd.1.auto: Cycle state = 0x1 [ 341.559305] xhci-hcd xhci-hcd.1.auto: New dequeue segment = ffff800073da9b40 (virtual) [ 341.567214] xhci-hcd xhci-hcd.1.auto: New dequeue pointer = 0xf710a750 (DMA) [ 341.574254] xhci-hcd xhci-hcd.1.auto: Queueing new dequeue state [ 341.580254] xhci-hcd xhci-hcd.1.auto: Set TR Deq Ptr cmd, new deq seg = ffff800073da9b40 (0xf710a000 dma), new deq ptr = ffff0000099c5750 (0xf710a750 dma), new cycle = 1 [ 341.595373] xhci-hcd xhci-hcd.1.auto: // Ding dong! [ 341.600243] xhci-hcd xhci-hcd.1.auto: Giveback URB ffff800071760540, len = 3072, expected = 3584, status = -75 [ 341.610241] xhci-hcd xhci-hcd.1.auto: Ignoring reset ep completion code of 1 [ 341.617283] xhci-hcd xhci-hcd.1.auto: Successful Set TR Deq Ptr cmd, deq = @f710a750 -115 13 < ffff[ 341.625130] xhci-hcd xhci-hcd.1.auto: Transfer error for slot 3 ep 2 on endpoint
