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 <[email protected]>
| Newsgroups | org.kernel.vger.linux-usb |
|---|---|
| Message-ID | <[email protected]> |
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