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

[JP Hein <jp@jphein.com>]

Hi Michal,

Three updates: the stock reproduction I owed you, a correction to my own
endpoint labeling that touches earlier mails, and what looks like a separate
usb-core regression on 7.x that you (or Greg's list) should probably see.

--- 1. Stock-kernel reproduction, full usbmon (2026-08-25) ---

Ubuntu kernel 7.0.0-30 (upstream 7.0.12 uvcvideo), no out-of-tree module of
any kind, camera on a 20-minute-old enumeration, video + microphone both
streaming in a WebRTC call. The controller died mid-call. usbmon was running
on the bus for the whole call (168MB, preserved).

Wire sequence, same two-phase lock I described on 06-13, now on stock:

  t0        app stops the stream; video URBs unlink cleanly (last frame
            completes status 0)
  t0+1ms    SET_INTERFACE alt0 (iface 1) submitted        -- Phase 1
  t0+5.16s  still unanswered; driver unlinks it (-2)
            (06-13 measured 5.4s; 05-30 measured 5.1-5.5s. Same number.)
  t0+5.16s  COMMIT_CONTROL SET_CUR submitted              -- Phase 2
  ...       COMMIT never completes. dmesg shows the escalation:
            "Timeout while waiting for evaluate context command"
            "Abort failed to stop command ring: -110"
            "xHCI host controller not responding, assume dead" -> HC died
  t0+23.6s  everything on the bus reaps -108/-2; the hung COMMIT
            error-completes and prints the familiar
            "Failed to set UVC commit control : -110" post-mortem.

Through Phase 1 and Phase 2 the microphone's iso endpoint streamed
healthily to within a few ms of HC death (sequence numbers advancing,
status 0). Control plane dead, data plane flowing -- consistent with
everything since 05-30.

Same afternoon, two more commit-control stalls on fresh enumerations were
caught early by my userspace watchdog (camera-only port cycle, no HC
death), also captured. So: the lock reproduces on stock, and -110/-32
remain "who reaped the hung COMMIT first", as before.

One honesty note on that day: the machine was concurrently in a CPU/memory
saturation incident (order-9 allocation fallbacks in uvc_alloc_urb_buffers
in the same window). I don't think it changes the mechanism -- the wire
signature is identical to the June captures taken at normal load -- but
the unusual event *frequency* that day shouldn't be read as clean data.

--- 2. Correction: EP 0x82 is the microphone, not video ---

I mislabeled an endpoint in my 06-06 and 06-13 mails and want it on the
record straight. From the descriptors and the wire:

  0x81  iso, wMaxPacketSize 0x400, 32 packets/URB, ~1MB buffers  = VIDEO
  0x82  iso, wMaxPacketSize 0x0c4 (196), 1 packet/URB @1ms       = AUDIO
        (196B payloads are plainly 48kHz S16 stereo PCM on the wire)
  0x85  interrupt, the wBytesPerInterval 8-vs-64 descriptor case = STATUS

So in my earlier mails: the "healthy iso video streaming through the
control stall" was the *microphone*; and the 06-06 "timeout: still 12
active urbs on EP #82" hang was the *microphone* endpoint, which also
means the mic was in active use in that crash. The two-phase structure
and ordering are unchanged (control plane leads, data follows), but any
reasoning that leaned on "video specifically wedges" should be discarded
-- in the 08-25 stock capture, video had already stopped cleanly before
Phase 1, and audio was the surviving stream.

--- 3. EP5 on stock: still no flood ---

The 08-25 stock capture has EP 0x85 at 5 events total across the whole
call -- every one a teardown artifact (2x ENOENT unlink, ESHUTDOWN at HC
death). Zero short-packet completions. That closes the loop from 06-13:
the absence of an EP5 COMP_SHORT_PACKET flood is now demonstrated on
stock as well, so hypothesis A (EP5 underallocation -> ring congestion)
is out on both driver variants. The lock is (B): a device/controller
reconfiguration hang independent of the EP5 descriptor bug.

--- 4. Separate finding: NO_LPM quirk not applied on 7.x ---

While investigating I found the merged quirk from patch 1 of my series
(usb-core quirks table entry for 1532:0e05, USB_QUIRK_NO_LPM) does not
take effect on the 7.0 kernels I can test:

  - the entry is present in 7.0 sources (drivers/usb/core/quirks.c), and
    'k' still maps to USB_QUIRK_NO_LPM in the dynamic-quirk parser;
  - I additionally boot with usbcore.quirks=1532:0e05:k (verified live in
    /sys/module/usbcore/parameters/quirks);
  - yet after every enumeration the device shows
    power/usb3_hardware_lpm_u1 = enabled, and the sysfs quirks attribute
    reads 0x10 only (the RESET quirk my udev rule adds) -- no 0x100.

So this camera -- quirked upstream precisely because LPM destabilises its
firmware -- has been running with U1 active on every 7.x kernel here. I
can't yet say whether that raised the lock's frequency (see the load
caveat above), but a merged NO_LPM quirk silently not applying seems
worth a report to linux-usb regardless of this camera; I intend to send
one after bisecting whether it's the static table, the dynamic parser, or
the application point in hub.c that regressed. If you've seen anything
like this on 7.x I'd be glad of a pointer. As a stopgap I now call
usb_disable_lpm() from a local uvcvideo build's probe for this device,
and the device then holds u1/u2 disabled.

--- Still owed ---

Item 3 from my last mail (A/B on your 6.17-xhci-test branch) is still
open, with a wrinkle: my stock baseline has moved to 7.0, so a 6.17 A/B
would no longer be apples-to-apples. If you have (or want) a 7.x rebase
of the test patch I'll run it; otherwise I can boot the old 6.17 pair and
accept the version skew for the comparison.

Captures + analysis: https://github.com/jphein/kiyo-xhci-fix
  crash-evidence/auto-captures/CRASH-20260825T212701Z-4events.txt.gz
      (stock HC death, full call, 168MB raw / 34MB gz)
  crash-evidence/auto-captures/CRASH-20260825T213016Z-*.gz, -213154Z-*.gz,
      -220834Z-*.gz  (same-day precursor stalls, incl. one on the local
      LPM-workaround build)
  crash-evidence/2026-08-25-stock-hc-crash/  (watchdog dump + notes)

JP