Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware

Jeffrey Hein
2026-04-10T23:06:55Z

On Sat, 11 Apr 2026 00:48:05 +0300, Mathias Nyman wrote:
> One theory could be that xHC control endpoint refuses to restart when its
> dequeue pointer is moved to a no-op TD like in this case (second cancelled
> URB).
>
> This can happen when we cancel two control URBs at the same time.

I tested Michal's xhci patch (max_esit_payload clamp + short packet
err_count reset) on a custom 6.17.0 kernel. Two separate tests below.

Hardware: Intel Cannon Lake PCH xHCI (8086:a36d)
Device: Razer Kiyo Pro (1532:0e05), bcdDevice 8.21
Kernel: 6.17.0-xhci-test (vanilla 6.17 + Michal's patch)

max_esit_payload 8 -> 64 confirmed firing at boot for EP5IN.

Test 1: Michal's xhci patch + JP's UVC patches + NO_LPM
=========================================================
Active: usbcore.quirks=1532:0e05:k (NO_LPM), DKMS uvcvideo with
UVC_QUIRK_CTRL_THROTTLE, Michal's xhci patch.

Result: HC died. The crash sequence from the full log:

1) 437 repeated Cancel/resubmit cycles on EP5 IN (ep 0x85, slot 5
ep 10) over ~7 minutes starting mid-call:

[15:18:58] Cancel URB 0000000028356cb5, dev 3.1, ep 0x85, starting
at offset 0x114a49080
[15:18:58] Stopped on Transfer TRB for slot 5 ep 10
... (437 cancel/resubmit cycles through 15:26:04)

This is the same "repeated unlinks on EP5IN" pattern you noted in
the March 30 stall-6.17-stress-during-call log, Michal.

2) After the last ep 0x85 cancellation + endpoint reconfigure (add
ep 0x81), ~994,000 spurious SHORT_PACKET events (comp_code 13)
flooded the HC for ~5 minutes:

[15:26:04] add ep 0x81, slot id 5
[15:26:04] Successful Endpoint Configure command
[15:26:04] Spurious event dma ..., comp_code 13 after 13
... (~993,703 spurious events through 15:30:48)

3) Control transfers started timing out, with miss service interval
errors on isochronous eps 2 and 4:

[15:30:48] Cancel URB ..., dev 3.1, ep 0x0
[15:30:53] Cancel URB ..., dev 3.1, ep 0x0 (5s stop-ep timeout)
[15:30:53] ThreadPoolSingl timed out on ep0in len=0/2
[15:30:53] Failed to query (GET_CUR) UVC control 6 on unit 1: -110
[15:30:59] Cancel URB ..., dev 3.1, ep 0x0
[15:31:04] Command timeout, USBSTS: 0x00000000
[15:31:04] xHCI host controller not responding, assume dead

Full log (2.9MB gz, 1.06M lines):
https://github.com/jphein/kiyo-xhci-fix/blob/main/kernel-patches/crash-evidence/crash-6.17.0-xhci-test-20260410-152541.log.gz

Test 2: Michal's xhci patch ONLY (clean isolation)
====================================================
Active: ONLY Michal's xhci patch. No usbcore.quirks cmdline, stock
uvcvideo (DKMS module disabled), LPM and autosuspend at defaults.

Result: HC survived.

Video call ran successfully. Then ran stress test (rapid v4l2-ctl
control transfers -- focus, white balance, exposure, zoom, brightness
cycling). Firmware locked at round ~23:

[336.489500] usb 2-3.1: pipewire timed out on ep0out len=0/0
[336.489503] usb 2-3.1: disable of device-initiated U1 failed.
[336.489510] usb 2-3.1: v4l2-ctl timed out on ep0out len=0/8
[336.504055] Transfer error for slot 36 ep 10 on endpoint
... (repeating timeout/error cycle every ~5s)

Device firmware was completely unresponsive, but the host controller
survived. No hc_died(). The transfer errors were on ep 10 (EP5 IN,
the endpoint Michal's patch targeted).

Full log (1.2MB gz):
https://github.com/jphein/kiyo-xhci-fix/blob/main/kernel-patches/crash-evidence/crash-6.17.0-xhci-test-20260410-154243.log.gz

Full dmesg:
https://github.com/jphein/kiyo-xhci-fix/blob/main/kernel-patches/crash-evidence/michal-only-stress-20260410.log

Summary
========
In both tests, EP5 IN (interrupt, wBytesPerInterval=8) was at the
center of the problem. In Test 1, the repeated unlinks on EP5 IN
led to a spurious event flood that eventually killed the HC. In
Test 2, EP5 IN had transfer errors but the HC handled them without
dying.

The key variable between the tests was the UVC throttle and NO_LPM,
not Michal's xhci patch (which was active in both). I don't yet
understand why the additional UVC-layer mitigations would make the
HC outcome worse, not better. Different test conditions (stream
teardown in Test 1 vs active streaming in Test 2) may explain it.

Michal, re: lsusb -- I built usbutils 019 from source and confirmed
it decodes wBytesPerInterval natively:

Endpoint Descriptor:
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 8
bMaxBurst 0
wBytesPerInterval 8

Full lsusb -v (usbutils 019, 927 lines):
https://github.com/jphein/kiyo-xhci-fix/blob/main/kernel-patches/crash-evidence/lsusb-v-kiyo-pro-usbutils019.txt

v7 patch 2/2 included lsusb -vv (934 lines). If lsusb -v is preferred
I can swap it in a v8.

I have other Intel machines available for testing if you'd like to
confirm this isn't Cannon Lake-specific. No AMD hardware currently.

JP