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 20:31:17 +0300, Дмитрий wrote:
> 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:

This looks like high data loss on the isoc endpoint.

> * 8,781 "Spurious event dma ..., comp_code 13 after 13"

Probably harmless. While it could be some unknown bug, it usually
is just a normal condition when multi-TRB TDs are present.

It may go away with certain other combinations of video format,
resolution and frame rate (namely: those where alt settings with
power-of-two packet size are used, and you can know selected alt
setting by passing trace=0x400 module parmatere to uvcvideo).

> * 6,309 "Miss service interval" events
> * 4,073 "Found td. Clear skip flag" events

This number of Missed Service Errors is excessive and may be the main
reason for data loss. Unfortunately, I don't konw what causes it. Some
users reported seeing correlation with CPU load (it may go both ways -
either high or low CPU load causes errors).

It notably shouldn't be affected by scheduling patches in usb-next,
because uvcvideo uses URB_ISO_ASAP. And you say the bug is very old.

Maybe it's something to do with multi-TRB TDs? Would it get any better
in video modes that don't produce "spurious events"?

> * 23 "Giveback URB" events
> * 0 "All TDs skipped" events
> * 0 DMAR/IOMMU faults

Good, the "All TDs skipped" and "Event dma" bug is fixed now.

> 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

These are very fast submit-unlink cycles, it doesn't look like the
URBs are unlinked due to failing to complete for a long time, but more
like uvcvideo "changed its mind" for some reason. No problem?

Then it's 45 seconds of Missed Service Errors, which looks like the
actual problem and the reason why video frames are being lost.

> * 5 "Stopped on Transfer TRB" messages for slot 4 ep 2, corresponding
>    to the isochronous video endpoint 0x81

And 5 video URBs are unlinked when v4l2-ctl exists. Normal.

> 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

Windows must be doing something differently. But again, the problem
seems to be with xHCI, not any control requests sent to the camera.

Regards,
Michal