Re: [BUG] xhci: repeated URB cancel on UVC status interrupt EP (0x83) loops for ~15s, stalls camera - Intel Cannon Point-LP [8086:9ded]

[Michal Pecio <michal.pecio@gmail.com>]

On Sun, 23 Aug 2026 23:10:26 +0300, Дмитрий wrote:
> I temporarily reloaded uvcvideo with quirks=0x80. The selected
> streaming configuration changed from altsetting 7 with 3072 B/frame
> to the following power-of-two configuration:
> 
> Device requested 1024 B/frame bandwidth
> Selecting alternate setting 3 (1024 B/frame bandwidth)
> Allocated 5 URB buffers of 32x1024 bytes each
> 
> Without dynamic debugging, one 300-buffer run completed with rc=0:
> 
> duration: 17.941 seconds
> delivered buffers: 300
> reported sequence gaps: 217
> effective delivered rate: 16.72 fps
> delivered positions: 58.03%

Not sure what's "sequence gaps"?

> A five-second xHCI tracepoint capture contained 39,136 queued
> isochronous TRBs. All of them had this layout:
> 
> length=1024 td_size=0 tbc=0 tlbpc=0
> 
> There were no 3072-byte isochronous TRBs. The same trace interval
> contained 339 Missed Service Error events.

I suppose that's correct for a 1KB high-speed endpoint, but errors are
still there. Looking at the trace, they come in bursts of three.

The first one has non-zero TRB pointer and also "len 1012", which is
practically guaranteed to be bogus, as it doesn't seem packet-aligned,
so receiving 12 bytes should complete the TRB right there.

Not sure if the garbage data affect uvcvideo or if it is only bothered
by the -EXDEV status. I suppose this would hide the garbage:

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2421,7 +2421,7 @@ static void process_isoc_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep,
 		break;
 	case COMP_MISSED_SERVICE_ERROR:
 		frame->status = -EXDEV;
-		sum_trbs_for_length = true;
+		requested = 0;
 		if (ep_trb != td->end_trb)
 			td->error_mid_td = true;
 		break;

Curiously, the errors always seem to happen during runs of Short Packet
with len 1012, which means the camera is just returning a 12 byte UVC
header and not sending anything meaningful. In theory, it might perhaps
be recoverable at UVC layer with some heuristics. But I don't know if
that's what Windows is doing, or if it simply avoids having MS errors
in the first place.

There seems to be no issue with submission timing, the TDs which are
missed have been submitted 17ms earlier. Besides, they are ASAP.

It could be some power management issue. Any chance it goes away if you
add CPU load, or memory load like memtester or stress/stress-ng with
appropriate options? Some recent AMD systems seemed to need that, IIRC
no one found a proper solution yet. There was some discussion about
setting latency tolerance, seems no one actually tried it.

Regards,
Michal