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

Hi, The built-in UVC webcam on an ASUS VivoBook X509FL freezes after a fewrapid stream restart cycles: video hitches for a second at random, thenstalls completely for ~15 s before recovering on its own. ftrace ofxhci-hcd points at a repeated URB-cancel loop on the camera's VideoControlstatus interrupt endpoint (0x83), not at the isoc video stream. This is not application-specific and not a regression. It reproduces witha plain v4l2-ctl restart loop (no browser/Zoom), and behaves the same on6.8.11, 6.11.11 and 7.1.3 (Fedora builds); the dmesg event storm is justmore verbose on 6.12+. Hardware:- Intel Cannon Point-LP USB 3.1 xHCI Controller [8086:9ded] (rev 30)- Camera: 13d3:5a11 "USB2.0 VGA UVC WebCam", UVC 1.00  - EP 0x81: isochronous video (VideoStreaming, 8 alt settings, max    alt 7 = 3x1024 B/uframe), appears as "ep 2" in the xhci context  - EP 0x83: interrupt IN (VideoControl status)- No ALSA device is exposed by the camera; audio is not involved. Reproducer (no application needed):     # continuous single stream - always stable, 30 fps, never stalls:    timeout 120 v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=3600     # rapid STREAMON/STREAMOFF loop - stalls within a few iterations    # (v4l2-ctl hangs, zero frames), recovers by itself after ~15 s:    for i in $(seq 1 40); do        v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=120        echo "run $i: $?"    done ftrace (events: xhci-hcd) captured while reproducing. During the stall,one URB on ep 0x83 is cancelled 68 times over ~14.7 s (t=6119.476 ..6134.178), each iteration advancing TR Deq Ptr by exactly one TRB (0x10):     xhci_dbg_cancel_urb: Cancel URB 00000000978a08ef, dev 5, ep 0x83, starting at offset 0x1167e9440    xhci_handle_cmd_stop_ep: ...    xhci_dbg_cancel_urb: Removing canceled TD starting at 0x1167e9440 (dma) in stream 0 URB 00000000978a08ef    xhci_dbg_cancel_urb: Set TR Deq ptr 0x1167e9450, cycle 0    xhci_handle_cmd_set_deq_ep: ...    xhci_dbg_cancel_urb: Successful Set TR Deq Ptr cmd, deq = @1167e9450    xhci_dbg_cancel_urb: Cancel URB 00000000978a08ef, dev 5, ep 0x83, starting at offset 0x1167e9450    ... (repeats, deq crawling +0x10 each time: 440 -> 450 -> 460 -> ...) ep 0x81 shows 10 cancels in the same window. Note the trace logs"in stream 0" for an interrupt endpoint, which has no streams - possiblyrelevant. As a side effect, the isoc video endpoint (0x81 / "ep 2") floods dmesgduring the stall:     xhci_hcd 0000:00:14.0: Event dma 0x... for ep 2 status 13 not part of TD at 0x...    xhci_hcd 0000:00:14.0: Event dma 0x... for ep 2 status 1  not part of TD at 0x...    xhci_hcd 0000:00:14.0: Event TRB for slot 4 ep 2 with no TDs queued The USB control path is clean: usbmon shows the standard UVC restart(VS_PROBE/COMMIT SET_CUR/GET_CUR, then SET_INTERFACE alt 7 / alt 0)completing without any STALL. The device responds correctly; the failureis on the xHCI cancel/set-deq side. Attached:- xhci ftrace (trace-cmd report output), the main exhibit- usbmon capture (bus 1) across the transition into the stall- dmesg fragment with the event storm- lsusb -v -d 13d3:5a11- lspci -nnvv -s 00:14.0 Happy to test patches, add dynamic debug, or capture more tracing. Thanks,Dmitry Link to files if weren't sent: https://pixeldrain.com/l/iPwNbqVf

31,971 lines not shown · raw message

Part of this message is not shown here. View the raw message.

Hi,

Please post in plain text (not HTML) to kernel mailing lists. Not all mail clients render HTML, not all that do make it easy to quote HTML.

There is something odd about your trace, not sure why the entries aren't decoded.

The dmesg fragment shows some serious breakage on the isochronous endpoint, it seems to jump to random places on the ring and execute completely wrong TDs, like failed or missing Set TR Dequeue?

Considering the above, I would suggest *enabling* IOMMU, because this chip is completely out of control and it may be DMA-ing to buffers that have been freed (uvcvideo doesn't generally free isoc buffers during streaming, but hell knowns if other endpoints aren't affected).

3990.653716 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c0af0 for ep 2 status 1 not part of TD at 00000001323c0b10 - 00000001323c0b10 3990.653718 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c0b00 for ep 2 status 1 not part of TD at 00000001323c0b10 - 00000001323c0b10 3991.385996 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c05a0 for ep 2 status 13 not part of TD at 00000001323c0e40 - 00000001323c0e40 3991.386003 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c05b0 for ep 2 status 13 not part of TD at 00000001323c0e40 - 00000001323c0e40 3991.386005 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c05c0 for ep 2 status 13 not part of TD at 00000001323c0e40 - 00000001323c0e40 3991.386007 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c05d0 for ep 2 status 13 not part of TD at 00000001323c0e40 - 00000001323c0e40 3991.386009 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c05e0 for ep 2 status 13 not part of TD at 00000001323c0e40 - 00000001323c0e40 3991.386018 xhci_hcd 0000:00:14.0: Event TRB for slot 4 ep 2 with no TDs queued
3991.386645 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c0630 for ep 2 status 13 not part of TD at 0000000119d858a0 - 0000000119d858a0 3991.386649 xhci_hcd 0000:00:14.0: Event dma 0x00000001323c0640 for ep 2 status 13 not part of TD at 0000000119d858a0 - 0000000119d858a0

Not sure what's the problem, if any, with the interrupt endpoint. Nothing about it shows up in the log snippet provided.

Maybe try to collect dmesg with xhci dynamic debug enabled:

echo 'module xhci_hcd +p' >/proc/dynamic_debug/control dmesg -W |tee log.txt

# connect the camera and reproduce the bug
# send log.txt

If you are feeling lucky, try if this patch from usb-next happens to fix it. It was seen to reduce occurrences of other bizarre problems.

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=7c0c31c66a7f9daace156bac427aafb2f4bbb5fc

Either add usb.git to your remotes and checkout this commit, or cherry-pick it on some recent kernel, or apply the diff manually, or wait for v7.3-rc1 which is expected to include this patch.

Does anything similar happen to other USB 2.0 webcams connected to external USB ports on the same USB bus number 1? I would say that a 15 second freeze may simply be a webcam issue, but those "Event dma" messages shouldn't be there.

Regards,
Michal

Hi Michal,

Thanks, and sorry about the previous HTML message. This reply is plain text.

I enabled the IOMMU using:

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

The boot log confirms:

|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.

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.

On a fresh boot of the patched kernel, with the same IOMMU parameters, seven completed iterations of the restart test all reached the 45-second timeout. Capturing 120 frames at 30 fps should normally take about four seconds, but each iteration delivered only zero or a few frames.

The non-dynamic-debug kernel log from that test contains:

|3922 Event dma ... not part of TD 28 Event TRB ... with no TDs queued |

Seven iterations completed before I stopped the test. The manually added stop marker at the end of patched-40-runs.log says "after_run=06" by mistake; run 07 has a complete result line.

I then rebooted the patched kernel again and repeated five iterations with xhci_hcd dynamic debug enabled. All five iterations again timed out. During the captured interval the log contains:

|27664 Miss service interval error 8131 Event dma ... not part of TD 7976 with status 13 155 with status 1 39 Event TRB ... with no TDs queued |

The first ring errors appeared less than one second after starting the first stream.

The VideoControl status URB behavior is still visible. The same URB:

|00000000e0807de4, dev 5, ep 0x83 |

was cancelled 115 times during the five-run capture. In the first batch it was cancelled 22 times in about 1.9 ms. Each successful Set TR Deq Ptr advanced the dequeue pointer by one TRB, for example:

|0xfff57660 -> 0xfff57670 0xfff57670 -> 0xfff57680 ... 0xfff577b0 -> 0xfff577c0 |

All 126 Set TR Deq Ptr commands in the capture reported success. There were no failed Set TR Deq commands, Host System Errors, kernel warnings, or IOMMU faults.

The isochronous endpoint 0x81 was cancelled 25 times during the same capture. Its ring then produced the missed-service and stale transfer events listed above.

I do not know whether the repeated status-URB cancellation is causal. It may be related to UVC status endpoint stop/resume behavior. However, the patch clearly does not prevent the isochronous ring from becoming desynchronized.

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.

One caveat is that the external-camera test was performed in the same boot after testing the internal camera, so the controller had already produced ring errors earlier in that boot. The errors are associated with the C170's own slot 6 / ep 4 ring, but this was not a completely clean external-camera-only boot.

I have attached:

|iommu-summary.txt xhci-iommu-group.txt patched-uname.txt patched-cmdline.txt patched-40-runs.log patched-kernel-summary.txt.xz patched-dyndbg-5-runs.log patched-dyndbg-live.log.xz lsusb-tree-external.txt v4l2-external-all.txt external-restart-loop.log external-kernel-summary.txt.xz restart-test.sh |

Please let me know what additional tracing would be most useful, or if there is another patch you would like me to test.

Regards,
Dmitry

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.

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

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.

Yep, looking like a host controller bug.

Regards,
Michal

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 пишет:

This looks like high data loss on the isoc endpoint.

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).

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"?

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

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.

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

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

Is the camera still unusable with this new kernel if you disable all debugging?

With the "All TDs skipped" issue fixed the driver should now be in sync with the isoch ring.

Could you take a short xhci trace of this issue?

It should show the content of those TRBs in mode detail. TRB fields like TD size are more important in Multi-TRB TDs. Controller uses those for scheduling.

mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable echo 1 > /sys/kernel/debug/tracing/tracing_on
< Reproduce issue >
Send content of /sys/kernel/debug/tracing/trace

Content of HCCPARAMS2 register and USBCMD register would also be useful as those dictate how the TRB fields are interpreted.

cat /sys/kernel/debug/usb/xhci/0000:00:14.0/reg-cap cat /sys/kernel/debug/usb/xhci/0000:00:14.0/reg-op

Thanks
Mathias

Hi Mathias, Michal,

Thank you for the analysis and the requests for additional data.

I made a final set of tests on the Fedora 44 kernel containing both commits:

7c0c31c66a7f9daace156bac427aafb2f4bbb5fc
3d9eeb336131bc5a174367c384fa00c15c8744fd

The running kernel was:

7.1.8-200.xhci3d9eeb3.fc44.x86_64

IOMMU remained enabled in translated, strict mode:

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

No DMAR or IOMMU fault was observed.

## Behavior without debugging

At 640x480 YUYV and a requested 30 fps, with exposure_dynamic_framerate=1, a normal 120-frame run timed out after 45.034 seconds with rc=124.

With exposure_dynamic_framerate=0, the camera is no longer completely stuck, but the video is still not usable as a smooth stream:

* One 120-frame run completed in 15.109 seconds, giving an effective 7.94 delivered fps and 304 skipped sequence numbers.
* Five consecutive restart runs all completed with rc=0, but their effective delivered rates ranged from 3.71 to 21.08 fps.
* Across those five runs, 600 buffers were delivered and 1477 sequence gaps were reported over 75.143 seconds.

The visible result is a working picture with frequent and sometimes long freezes. Therefore fixing the "All TDs skipped" condition restored ring synchronization, but did not make the camera practically usable at its default setting.

## UVC alternate setting

With uvcvideo trace=0x400, both values of exposure_dynamic_framerate selected the same streaming configuration:

Device requested 3072 B/frame bandwidth Selecting alternate setting 7 (3072 B/frame bandwidth) Allocated 5 URB buffers of 32x3072 bytes each

Thus changing exposure_dynamic_framerate does not change the USB alternate setting in the 640x480 tests.

## xHCI tracepoint captures

I captured two complete eight-second xHCI tracepoint windows with room lighting on. xHCI dynamic debug was disabled. Both streams were deliberately terminated after eight seconds, so rc=124 in these two trace result files only denotes the intentional timeout.

For exposure_dynamic_framerate=1:

* interval: 8.048177 seconds
* trace entries: 198668/198668, with no trace-buffer loss
* raw trace size: 40,648,949 bytes
* completed buffers printed by v4l2-ctl: 0
* camera isochronous URBs enqueued/given back: 1972/1972
* camera isochronous TRBs queued: 65076
* Missed Service Errors for slot 4 endpoint ID 3: 4260

For exposure_dynamic_framerate=0:

* interval: 8.052311 seconds
* trace entries: 201441/201441, with no trace-buffer loss
* raw trace size: 40,942,997 bytes
* completed buffers printed by v4l2-ctl: 51
* sequence gaps reported by v4l2-ctl: 167
* camera isochronous URBs enqueued/given back: 1973/1973
* camera isochronous TRBs queued: 65109
* Missed Service Errors for slot 4 endpoint ID 3: 1514

Disabling dynamic frame rate therefore reduced the number of Missed Service Errors by about 64.5%, but did not eliminate them or the visible frame loss.

Neither exact trace window contains "All TDs skipped", "Event dma ... not part of TD", or "no TDs queued". This seems consistent with commit 3d9eeb336131 fixing the previous ring-desynchronization condition.

## TRB layout

Each 98304-byte camera URB consists of 32 isochronous packets of 3072 bytes. The trace contains 33 TRBs per URB because one 3072-byte packet crosses a 64 KiB boundary and is represented by a multi-TRB TD:

* Isoch TRB: length 1024, TD size 2, TBC 0, TLBPC 2
* Normal TRB: length 2048, TD size 0

The remaining 31 packets use one 3072-byte Isoch TRB each, with TBC 0 and TLBPC 2. The layout is the same with exposure_dynamic_framerate=1 and 0.

The README in the Linux attachment also contains a breakdown of which TRBs the Missed Service Error event pointers mapped to. The attachment contains both complete raw trace files.

The status interrupt endpoint behavior is now also clearer. Each trace contains a burst of 21 cancel/set-dequeue operations for USB endpoint 0x83 during stream setup. The bursts last only about 1.77 ms, followed by one final cancellation during teardown roughly eight seconds later. There is no 15-second cancellation interval in these captures. This supports the interpretation that the status endpoint activity is not the cause of the continuing video loss.

## Requested registers

The requested register values are:

HCCPARAMS2 = 0x0000007d
USBCMD     = 0x00000005

Complete reg-cap and reg-op dumps are included in the Linux attachment.

## Lower-resolution test

I also tried 320x240 YUYV at a requested 30 fps with exposure_dynamic_framerate=0 and no debugging.

The run completed with rc=0 and delivered all 300 requested buffers, but it took approximately 50 seconds and reported 1171 skipped sequence numbers. That is an effective delivered rate of about 6.0 fps, with only 20.39% of sequence positions delivered.

Therefore reducing the resolution did not improve the practical result in this run.

Unfortunately, the trace=0x400 journal capture attempted for this mode returned no entries. I therefore do not know which alternate setting or packet size was selected at 320x240, and cannot claim that this was a power-of-two packet-size test. The raw user-space result is included in the Linux attachment.

## Windows 10 comparison

I also tested the same built-in camera on the same laptop under Windows 10 Pro 22H2, using 640x480 YUY2 at a requested 30 fps, automatic exposure and constant bright external lighting.

With Windows Low Light Compensation enabled:

* 300 frames took 43.185 seconds wall-clock
* effective delivered rate: 6.95 fps

With Low Light Compensation disabled:

* FFmpeg captured 300 frames in 10.04 seconds
* FFmpeg stream rate: 29.88 fps
* total process time including startup and shutdown: 11.446 seconds

I then performed 40 consecutive stream restarts with Low Light Compensation disabled. Every individual FFmpeg log reached its final 120-frame record. The streams took approximately 3.99 to 4.06 seconds each at 30 fps; total process durations including startup and shutdown were 5.380 to 5.554 seconds. No 15-second stall occurred.

A short Windows USB ETW capture from a successful 120-frame run is also included. I understand that it does not expose xHCI transfer-ring state or TRB fields at the same level as the Linux tracepoints, so I provide it mainly as a behavioral comparison.

This makes the comparison quite pronounced: disabling the corresponding low-light/dynamic-frame-rate behavior gives Windows a stable 30 fps stream and reliable restarts, while under Linux it only partially reduces Missed Service Errors and leaves severe frame loss.

## Attachments

Link to cloud if email attachments lost https://kurio.infini-cloud.net/share/1362a122e3d32c97

SHA-256:
2233b31480164e1ba0ef20fb508b24d7476980f03bd14933cb7cab11394b258c

This contains the full Linux xHCI traces, register dumps, UVC alternate setting logs, no-debug A/B tests, the 320x240 result, hardware descriptors, IOMMU information, README and a SHA-256 manifest.

bright-30fps-20260820-232926.tar.gz
SHA-256:
0fb7ca37b1ad88e6ce2afce137ae694093d46bc03db4c6123e3df39e258855d4

This contains the Windows bright-light A/B test, all 40 restart logs and the ETW capture.

This is the final set of captures I can provide for now. I hope the raw TRB data and the Linux/Windows comparison are useful.

Regards,
Dmitry

20.08.2026 11:21, Mathias Nyman пишет:

Not sure what this is, possibly V4L2_CID_EXPOSURE_AUTO_PRIORITY, which maps to UVC_CT_AE_PRIORITY_CONTROL. From UVC 1.1 spec:

The Auto-Exposure Priority Control is used to specify constraints on the Exposure Time Control when the Auto-Exposure Mode Control is set to Auto Mode or Shutter Priority Mode. A value of zero indicates that the frame rate must remain constant. A value of 1 indicates that the frame rate may be dynamically varied by the device. The default value is zero (0).

I have no idea what this means and how the camera is expected to keep constant framerate if exposure gets longer than frame period, or why wouldn't it keep constant framerate when exposure time is shorter.

Not sure why this seems to affect isoc endpoint behavior. Maybe it was just random run-to-run variation? See below:

640x480 YUYV at 30fps is 2.3KB per ESIT. For a smaller altsetting, you need lower resolution or framerate, or compression like MJPEG.

Regards,
Michal

Hi Michal,

Thanks. Yes, exposure_dynamic_framerate appears to be V4L2_CID_EXPOSURE_AUTO_PRIORITY / UVC_CT_AE_PRIORITY_CONTROL.

I agree that the Linux A/B captures are not sufficient to prove that this control directly affects the number of Missed Service Errors. The results without tracing varied substantially between runs, from 3.71 to 21.08 delivered fps, so some of the difference between 4260 and 1514 MSEs may be run-to-run variation.

The Windows comparison makes the control interesting, but does not establish the Linux xHCI mechanism: under the same bright lighting, Windows delivered 6.95 fps with Low Light Compensation enabled and 29.88 fps with it disabled, followed by 40 successful stream restarts.

I repeated the 320x240 YUYV, 30 fps test with exposure_dynamic_framerate=0 and successfully captured the uvcvideo trace=0x400 output this time.

The run completed with rc=0 and delivered 300 buffers in 31.065 seconds, corresponding to an effective delivered rate of 9.66 fps. There were 620 reported sequence gaps, so only 32.61% of the observed sequence positions were delivered.

Despite the lower resolution, the camera selected exactly the same USB streaming configuration as at 640x480:

Device requested 3072 B/frame bandwidth Selecting alternate setting 7 (3072 B/frame bandwidth) Allocated 5 URB buffers of 32x3072 bytes each

Therefore, lowering the resolution to 320x240 did not cause the device to select a smaller or power-of-two payload size. It also did not solve the practical frame-delivery problem. This result consequently does not directly test the power-of-two packet-size hypothesis, because the camera still requests 3072 bytes for this mode.

Regards,
Dmitry

22.08.2026 10:25, Michal Pecio пишет:

I suppose this setting just affects exposure time. Since frame period can't be shorter than exposure, frame rate sometimes slows down.

At any rate, Windows appears to have no problem with data loss.

Try

rmmod uvcvideo
modprobe uvcvideo trace=0x400 quirks=0x80

and then experiment with various video modes.

Regards,
Michal

Hi Michal,

I tried the requested UVC_QUIRK_FIX_BANDWIDTH workaround. For a direct comparison, I used the same 320x240 YUYV mode at a requested 30 fps, with exposure_dynamic_framerate=0.

The test was performed on:

7.1.8-200.xhci3d9eeb3.fc44.x86_64

This kernel contains both:

7c0c31c66a7f9daace156bac427aafb2f4bbb5fc
3d9eeb336131bc5a174367c384fa00c15c8744fd

IOMMU remained enabled in translated, strict mode, and there were no DMAR or IOMMU faults.

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%

For comparison, the previous run in exactly the same video mode but without quirks=0x80 selected altsetting 7 with 3072 B/frame and produced:

duration: 31.065 seconds
delivered buffers: 300
reported sequence gaps: 620
effective delivered rate: 9.66 fps
delivered positions: 32.61%

Thus, quirks=0x80 reduced the reported gaps by about 65% and increased the effective delivered rate by about 73%, although the stream was still far from a smooth 30 fps.

I also ran five consecutive 120-buffer restarts without debugging. All five completed with rc=0. In aggregate they delivered 600 buffers in 38.736 seconds, with 441 reported sequence gaps:

effective delivered rate: 15.49 fps
delivered positions: 57.64%

The individual runs took between 7.120 and 8.422 seconds, corresponding to effective delivered rates of approximately 14.25 to 16.85 fps.

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.

In a separate five-second xHCI dynamic-debug interval I observed:

147 Miss service interval
0 Spurious event dma
0 All TDs skipped
0 Event dma ... not part of TD
0 Event TRB ... with no TDs queued
0 DMAR/IOMMU faults

The tracepoint and dynamic-debug counts came from separate intervals, so the two Missed Service Error counts should not be compared directly.

This seems to show that avoiding the 3072-byte layout has a substantial positive effect and removes the "Spurious event dma" messages in this sample. However, it does not solve the problem: many service intervals are still missed, and only about 15-17 frames per second are actually delivered.

I have attached the complete results, including the raw 25 MB xHCI trace, dynamic-debug log, UVC negotiation log, and stream logs:

fix-bandwidth-320x240-20260823-225712.tar.gz

SHA-256:

2e4016bdc4753d404a9e6b6f839ebbb8ce8a95957133430ed639914d4c66cf34

Regards,
Dmitry

22.08.2026 11:46, Michal Pecio пишет:

Not sure what's "sequence gaps"?

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:

@@ -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