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

Hi Michal,

I tested the suggested commit:

3d9eeb336131bc5a174367c384fa00c15c8744fd

on top of Fedora kernel 7.1.8 with the earlier commit
7c0c31c66a7f9daace156bac427aafb2f4bbb5fc also applied.

The resulting kernel was:

7.1.8-200.xhci3d9eeb3.fc44.x86_64

COPR build:

https://copr.fedorainfracloud.org/coprs/vertigo-red/kernel-xhci-deq/build/10875339/

IOMMU remained enabled in translated, strict mode:

intel_iommu=on iommu.passthrough=0 iommu.strict=1

There were no DMAR or IOMMU faults.

A journal-cursor-bounded run with dynamic debug enabled for
drivers/usb/host/xhci-ring.c timed out after 45.026 seconds:

rc=124

The v4l2-ctl output contained 22 capture markers and reported 239
dropped buffers. During the exact test interval, the kernel logged:

* 8,781 "Spurious event dma ..., comp_code 13 after 13"
* 6,309 "Miss service interval" events
* 4,073 "Found td. Clear skip flag" events
* 23 "Giveback URB" events
* 0 "All TDs skipped" events
* 0 DMAR/IOMMU faults

I then built and tested the complete usb-next tree at revision
bdab5605.

The resulting kernel was:

7.2.0-0.rc7.260818.bdab5605.358.usbnext.fc44.x86_64

COPR build:

https://copr.fedorainfracloud.org/coprs/vertigo-red/kernel-usb-next/build/10875458/

After a clean reboot into that kernel, with the same IOMMU settings,
I enabled 69 dynamic-debug callsites in xhci-ring.c and ran one test.

It failed on the first attempt:

2026-08-18T20:13:13+03:00 start
2026-08-18T20:13:58+03:00 rc=124
duration: 45.026 seconds

v4l2-ctl printed only five capture markers, then reported 148 dropped
buffers, with no further frame markers before the timeout.

The corresponding kernel log covers exactly the same 45-second
interval and contains:

* 9,022 "Spurious event dma ..., comp_code 13 after 13"
* 8,096 "Miss service interval" events
* 5,385 "Found td. Clear skip flag" events
* 23 "Giveback URB" events
* 0 "All TDs skipped" events
* 0 DMAR/IOMMU faults

All 9,022 spurious events have completion code 13, and the event storm
continues throughout the whole test.

There is also more information about the two endpoints:

* 23 "Stopped on Transfer TRB" messages for slot 4 ep 6, corresponding
   to the camera's USB status interrupt endpoint 0x83
* 5 "Stopped on Transfer TRB" messages for slot 4 ep 2, corresponding
   to the isochronous video endpoint 0x81
* the same status-URB address appears in 23 "Giveback URB" lines:
   22 during the first logged second and one when the timed-out stream
   is stopped
* 27 "xhci_handle_cmd_set_deq: Giveback cancelled URB" messages
* 27 "xhci_handle_cmd_set_deq: All TDs cleared, ring doorbell"
   messages

Therefore, cancellation/set-dequeue processing was active even though
the exact older "Cancel URB" and "Set TR Deq" debug strings do not
appear in this xhci-ring.c-only capture.

It looks as though commit 3d9eeb336131 avoids the specific
"All TDs skipped" condition, but the workaround is not sufficient for
this controller. The stream still becomes unusable while the
missed-service and spurious completion-code-13 events continue.

The status-endpoint cancellation activity and the isochronous event
storm clearly occur in the same test interval. I still cannot tell
whether the status URB behavior is causal or merely another effect of
the host-controller problem.

For comparison, the camera works acceptably under Windows on the same
laptop, including stream restarts. Windows uses the standard
usbvideo.sys stack together with a Realtek Device MFT named
RsDMFT64.dll:

CLSID: {09824200-9A44-4B06-8C74-92D99E09B435}
INF: rtasus.inf / oem7.inf
section: RS_RGB_DMFT_CAMERA

I previously compared a Windows USBPcap capture with Linux usbmon.
UVC probe/commit was the same on both systems:

* 640x480 YUYV
* dwFrameInterval = 333333
* dwMaxPayloadTransferSize = 3072
* SET_INTERFACE alternate setting 7

Windows additionally sent some eight-byte Extension Unit requests to
selector 0x0a. Replaying the observed sequence on Linux produced the
same STALL/OK results as Windows and did not change the Linux behavior.

Static analysis of RsDMFT64.dll showed that it is primarily a software
post-processing component (temporal noise reduction, software
auto-deflicker, ROI/AE processing and image transforms), so that part
is probably separate from the current xHCI restart failure.

Would any Windows-side information be useful for diagnosing the host
controller behavior? I can provide or collect, as requested:

* a USBPcap trace of repeated camera stream start/stop cycles
* a Windows USB/UCX ETW trace
* versions and hashes of USBXHCI.SYS, UCX01000.SYS and USBVIDEO.SYS
* versions and hashes of RsDMFT64.dll and rtasus.inf
* USB descriptors and relevant Windows power-management settings
* the RsDMFT64.dll binary privately, if it is useful and appropriate

Please let me know which artifact and capture method would be most
useful.

I have attached . It contains
the reproducer, hardware descriptors, kernel metadata, enabled
dynamic-debug callsites and the complete cursor-bounded logs for both
the two-patch kernel and full usb-next.

Archive SHA-256:

a31d258ea16f4e7d709dbb0c97284480894d7e6f53b3412f62985919b3633e43

Happy to test further patches or collect a more targeted trace.

Regards,
Dmitry

18.08.2026 01:09, Michal Pecio пишет:
> 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