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 Tue, 18 Aug 2026 00:05:45 +0300, Дмитрий wrote:
> |DMAR: IOMMU enabled iommu: Default domain type: Translated iommu:
> DMA domain TLB invalidation policy: strict mode pci 0000:00:14.0:
> Adding to iommu group 5 |
> 
> There were no DMAR or IOMMU fault reports. The camera problem still
> reproduces.

OK, that's good. Probably nothing bad happened to you before.

But it's generally safer to have IOMMU enabled when dealing with
questionable hardware like that.

> I also built Fedora kernel 7.1.8 with commit
> 7c0c31c66a7f9daace156bac427aafb2f4bbb5fc applied:
> 
> |xhci: move dequeue to next valid td instead of past cancelled one |
> 
> The resulting kernel is:
> 
> |7.1.8-200.xhci7c0c31c.fc44.x86_64 |
> 
> The COPR build is available here:
> 
> |https://copr.fedorainfracloud.org/coprs/vertigo-red/kernel-xhci-deq/build/10873745/ 
> |
> 
> The patch does not fix the problem on this machine.

So let's try this one.
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=3d9eeb336131bc5a174367c384fa00c15c8744fd

The log below looks like it's another broken Intel chipset and "All TDs
skipped" is never good news, it probably should have been xhci_err()
rather than xhci_dbg()...

But anyway, commit above tries to work around this class of HW bugs.
Let's see if it's good enough for your chip.

[  137.538119] xhci_hcd 0000:00:14.0: Miss service interval error for slot 4 ep 2, set skip flag, skip now
[  137.538122] xhci_hcd 0000:00:14.0: Found td. Clear skip flag for slot 4 ep 2.
[  137.538124] xhci_hcd 0000:00:14.0: Miss service interval error for slot 4 ep 2, set skip flag
[  137.538125] xhci_hcd 0000:00:14.0: Miss service interval error for slot 4 ep 2, set skip flag
[  137.538127] xhci_hcd 0000:00:14.0: Found td. Clear skip flag for slot 4 ep 2.
[  137.538755] xhci_hcd 0000:00:14.0: Miss service interval error for slot 4 ep 2, set skip flag, skip now
[  137.538764] xhci_hcd 0000:00:14.0: All TDs skipped for slot 4 ep 2. Clear skip flag.
[  137.538766] xhci_hcd 0000:00:14.0: Miss service interval error for slot 4 ep 2, set skip flag
[  137.538768] xhci_hcd 0000:00:14.0: Miss service interval error for slot 4 ep 2, set skip flag
[  137.539589] xhci_hcd 0000:00:14.0: Spurious event dma 0x00000000ffc75230, comp_code 13 after 13
[  137.539595] xhci_hcd 0000:00:14.0: Event dma 0x00000000ffc75240 for ep 2 status 13 not part of TD at 00000000ffc75ae0 - 00000000ffc75ae0
[  137.539600] xhci_hcd 0000:00:14.0: Event dma 0x00000000ffc75250 for ep 2 status 13 not part of TD at 00000000ffc75ae0 - 00000000ffc75ae0

> I do not know whether the repeated status-URB cancellation is causal.
> It may be related to UVC status endpoint stop/resume behavior.

It might simply be that uvcvideo submits some interrupt URB when
starting recording and then unlinks it when stopping, so nothing wrong
with that, and actual problem is the isochronous stream getting stuck.

> I also tested a Logitech Webcam C170 (046d:082b) connected to external
> USB port 1-6 on the same USB 2.0 bus. It appeared as /dev/video2 and was
> tested at its default 640x480 YUYV, 30 fps setting.
> 
> All 16 completed restart attempts timed out after 45 seconds. The
> external camera used slot 6 / xHCI ep 4, and its log contains:
> 
> |9336 Event dma ... not part of TD 9176 with status 13 160 with status 1 
> 64 Event TRB ... with no TDs queued |
> 
> Thus a different USB 2.0 webcam can trigger the same class of ring
> corruption on a separate slot and endpoint.

Yep, looking like a host controller bug.

Regards,
Michal