Re: [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure

Jeffrey Hein
2026-04-18T17:26:24Z

On Mon, 13 Apr 2026 22:40:38 +0200, Michal Pecio wrote:
> For the record, reloading xhci-pci is usually enough to fix this.

You're right that reloading xhci-pci is a recovery path -- I'll note
it. The reason the cover letter says "hard reboot" is that when the HC
dies, every USB device on the bus disconnects with it, keyboard and
mouse included, so triggering the reload requires SSH from a second
machine, SysRq, or some other non-USB input path. For most users on a
single-machine desktop the practical recovery is a reboot. I'll reword
in the next respin to capture both: "recovery requires rmmod/modprobe
xhci-pci or a reboot; since the local input devices disconnect with
the HC, most single-machine users will reboot."

> That's a bit speculative, it's not entirely clear what happens here.
> 2 seems possible, but Stop Endpoint timeout and some weird error codes
> seen in those logs looks like problems with the HC.

Fair. I'll reword trigger #2 to drop the firmware-internals claim and
describe only what we can observe: sustained rapid control activity
correlates with the device entering a stalled state that then triggers
a separate xHCI-layer failure. Your dual-cancel discussion with Mathias
and the vendor-defined event 198 are the right place to characterise
the HC-side mechanism; these UVC patches don't claim to explain or fix
it.

> Do these patches actually make a practical difference?

For CTRL_THROTTLE vs no mitigation, yes -- and I should have led with
this. Without any patches the stress test crashes the HC reproducibly
at round ~25 (many dmesg captures on file). With CTRL_THROTTLE alone
the same stress test runs 500+ rounds without failure. I also tested
USB_QUIRK_NO_LPM, DISABLE_AUTOSUSPEND, and avoid_reset_quirk
individually via sysfs, and each failed to prevent the stress-test
crash in isolation; a combined udev rule with all three still crashed
at ~round 25. Only CTRL_THROTTLE (or the coarser
USB_QUIRK_DELAY_CTRL_MSG at 200 ms) prevented it.

Where my data is actually thin is the interaction with your xhci test
patch specifically. The Apr 10 runs comparing "full stack + your
patch" (HC died) against "your patch alone" (HC survived) are N=1
each, and the lock-up path is timing-sensitive, so I shouldn't be
drawing conclusions from single outcomes on that axis. Before
respinning, I'll run a replication matrix on 6.17:

* stock (no patches)
* stock + your xhci test patch
* stock + NO_LPM
* stock + NO_LPM + CTRL_THROTTLE
* stock + NO_LPM + CTRL_THROTTLE + your xhci test patch

each under two workloads -- control-spam only, and control-spam during
an active v4l2 stream -- at N >= 5 per cell, with xhci_hcd and usbcore
dynamic debug enabled. I'll post the matrix with logs before the next
respin. That should tell us whether CTRL_THROTTLE still earns its keep
once your xhci patch is applied, which is the real open question.

Two things I'll fold in regardless of how the matrix reads:

1. The cover-letter language fixes above.

2. Clarifying in the commit messages that CTRL_THROTTLE and the
device-table entry are a device-local firmware-workaround layer,
not a claim on the HC-side issue -- which is Mathias's territory
and I don't want to conflate them.

If the matrix shows the throttle doesn't buy anything above your xhci
patch, I'll say so plainly and we can discuss whether the device-table
entry alone (DISABLE_AUTOSUSPEND + NO_RESET_RESUME, matching the
Logitech Rally Bar entry in uvc_driver.c) is still worth landing on
its own.

Thanks for the pushback -- it forced me to look harder at my own data.

JP

On Mon, Apr 13, 2026 at 1:40 PM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Thu, 9 Apr 2026 17:28:29 -0700, JP Hein wrote:
> > The Razer Kiyo Pro (1532:0e05) is a USB 3.0 webcam whose firmware has
> > a well-documented failure mode that cascades into complete xHCI host
> > controller death, disconnecting every USB device on the bus --
> > including keyboards and mice, requiring a hard reboot.
>
> For the record, reloading xhci-pci is usually enough to fix this.
>
> > The device has two crash triggers:
> >
> > 1. LPM/autosuspend resume: Device enters LPM or autosuspend, fails
> > to reinitialize on resume, producing EPIPE (-32) on UVC SET_CUR.
> > The stalled endpoint triggers an xHCI stop-endpoint timeout, and
> > the kernel declares the host controller dead.
> >
> > 2. Rapid control transfers: sustained rapid UVC control operations
> > (hundreds over several seconds) overwhelm the firmware.
>
> That's a bit speculative, it's not entirely clear what happens here.
> 2 seems possible, but Stop Endpoint timeout and some weird error codes
> seen in those logs looks like problems with the HC.
>
> And I known that some HCs are reliably killed by stopping SuperSpeed
> UVC streams, at least with my camera.
>
> > Patch 1 of the original 3-patch series (USB_QUIRK_NO_LPM for
> > 1532:0e05) has been merged by Greg Kroah-Hartman and backported to
> > stable kernels 6.1, 6.6, 6.12, 6.18, and 6.19.
> >
> > This v7 series covers the remaining two UVC patches:
> >
> > Patch 1/2: UVC driver -- introduce UVC_QUIRK_CTRL_THROTTLE to
> > rate-limit all USB control transfers (50ms minimum interval) in
> > __uvc_query_ctrl().
> >
> > Patch 2/2: UVC driver -- add Razer Kiyo Pro device table entry with
> > UVC_QUIRK_CTRL_THROTTLE, UVC_QUIRK_DISABLE_AUTOSUSPEND, and
> > UVC_QUIRK_NO_RESET_RESUME.
>
> Do these patches actually make a practical difference?
>
> If I'm not mistaken, the results of testing on 6.17 are:
>
> 1. The original trigger (spamming UVC control requests alone) doesn't
> cause breakage anymore.
>
> 2. New problems are seen when doing the above while streaming video,
> and they are still seen even with the UVC patches applied.

--
Jeffrey Pine Hein
Just plain helpful.
jphein.com ☀️ techempower.org
(530) 798-4099