* [PATCH v5 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure
@ 2026-03-31 0:38 JP Hein
2026-03-31 0:38 ` [PATCH v5 1/3] USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam JP Hein
` (4 more replies)
0 siblings, 5 replies; 30+ messages in thread
From: JP Hein @ 2026-03-31 0:38 UTC (permalink / raw)
To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman
Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein
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.
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 SET_CUR operations
(hundreds over several seconds) overwhelm the firmware. The error-code query
(GET_CUR on UVC_VC_REQUEST_ERROR_CODE_CONTROL) amplifies the
failure by sending a second transfer to the already-stalling device,
pushing it into a full lockup and xHCI controller death.
This has been reported as Ubuntu Launchpad Bug #2061177, with reports
across kernel versions 6.5 through 6.8.
This series adds three patches:
Patch 1: USB core -- USB_QUIRK_NO_LPM to prevent Link Power Management
transitions that destabilize the device firmware.
Patch 2: UVC driver -- introduce UVC_QUIRK_CTRL_THROTTLE to rate-limit
SET_CUR control transfers (50ms minimum interval) and skip the
error-code query after EPIPE errors on affected devices.
Patch 3: UVC driver -- add Razer Kiyo Pro device table entry with
UVC_QUIRK_CTRL_THROTTLE, UVC_QUIRK_DISABLE_AUTOSUSPEND, and
UVC_QUIRK_NO_RESET_RESUME to address both crash triggers.
Together, these keep the device in a stable active state, prevent rapid
control transfer crashes, and avoid the power management transitions
that trigger the firmware bug.
Testing on 6.17.0-19-generic (Ubuntu 24.04 HWE) with dynamic debug
enabled and NO patches or workarounds applied:
- v4l2-ctl stress test (control transfers only): passes 50/50
- Starting a video call: triggers hc_died() via LPM disable failure
during isochronous stream setup
- Stress test during active video call: firmware stalls at round 19,
repeated endpoint stalls with -32 EPIPE
The 6.8 -> 6.17 xHCI error handling improvements help with control
transfer recovery, but the firmware lockup during video streaming still
cascades to hc_died(). The patches in this series prevent the firmware
from reaching the lockup state in the first place.
Changes since v4:
- Dropped stable CC (new quirks, not regression fixes)
- Updated cover letter with 6.17 test results
Changes since v3:
- Regenerated patches against media-committers next branch to fix
context mismatch (v3 was based on Ubuntu 6.8 source)
Tested on:
- Kernel: 6.17.0-19-generic (Ubuntu 24.04 HWE) and 6.8.0-106-generic
- Hardware: Intel Cannon Lake PCH xHCI (8086:a36d)
- Device: Razer Kiyo Pro (1532:0e05), firmware 1.5.0.1
Stress test, crash evidence, and debug logs:
https://github.com/jphein/kiyo-xhci-fix
JP Hein (3):
USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam
media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware
media: uvcvideo: add quirks for Razer Kiyo Pro webcam
drivers/media/usb/uvc/uvc_driver.c | 17 ++++++++++++++++
drivers/media/usb/uvc/uvc_video.c | 32 ++++++++++++++++++++++++++++++
drivers/media/usb/uvc/uvcvideo.h | 3 +++
drivers/usb/core/quirks.c | 2 ++
4 files changed, 54 insertions(+)
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH v5 1/3] USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam 2026-03-31 0:38 [PATCH v5 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein @ 2026-03-31 0:38 ` JP Hein 2026-03-31 0:38 ` [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware JP Hein ` (3 subsequent siblings) 4 siblings, 0 replies; 30+ messages in thread From: JP Hein @ 2026-03-31 0:38 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein, stable The Razer Kiyo Pro (1532:0e05) is a USB 3.0 UVC webcam whose firmware does not handle USB Link Power Management transitions reliably. When LPM is active, the device can enter a state where it fails to respond to control transfers, producing EPIPE (-32) errors on UVC probe control SET_CUR requests. In the worst case, the stalled endpoint triggers an xHCI stop-endpoint command that times out, causing the host controller to be declared dead and every USB device on the bus to be disconnected. This has been reported as Ubuntu Launchpad Bug #2061177. The failure mode is: 1. UVC probe control SET_CUR returns -32 (EPIPE) 2. xHCI host not responding to stop endpoint command 3. xHCI host controller not responding, assume dead 4. All USB devices on the affected xHCI controller disconnect Disabling LPM prevents the firmware from entering the problematic low- power states that precede the stall. This is the same approach used for other webcams with similar firmware issues (e.g., Logitech HD Webcam C270). Cc: stable@vger.kernel.org Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177 Signed-off-by: JP Hein <jp@jphein.com> --- drivers/usb/core/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index 9e7e49712..7c4038a1e 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -480,6 +480,8 @@ static const struct usb_device_id usb_quirk_list[] = { /* Razer - Razer Blade Keyboard */ { USB_DEVICE(0x1532, 0x0116), .driver_info = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL }, + /* Razer - Razer Kiyo Pro Webcam */ + { USB_DEVICE(0x1532, 0x0e05), .driver_info = USB_QUIRK_NO_LPM }, /* Lenovo ThinkPad OneLink+ Dock twin hub controllers (VIA Labs VL812) */ { USB_DEVICE(0x17ef, 0x1018), .driver_info = USB_QUIRK_RESET_RESUME }, -- 2.43.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-03-31 0:38 [PATCH v5 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 2026-03-31 0:38 ` [PATCH v5 1/3] USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam JP Hein @ 2026-03-31 0:38 ` JP Hein 2026-04-09 6:45 ` Ricardo Ribalda 2026-03-31 0:38 ` [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam JP Hein ` (2 subsequent siblings) 4 siblings, 1 reply; 30+ messages in thread From: JP Hein @ 2026-03-31 0:38 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein, stable Some USB webcams have firmware that crashes when it receives rapid consecutive UVC control transfers (SET_CUR). The Razer Kiyo Pro (1532:0e05) is one such device -- after several hundred rapid control changes over a few seconds, the device stops responding entirely, triggering an xHCI stop-endpoint command timeout that causes the host controller to be declared dead, disconnecting every USB device on the bus. The failure is amplified by the standard UVC error-code query: when a SET_CUR fails with EPIPE, the driver sends a second transfer (GET_CUR on UVC_VC_REQUEST_ERROR_CODE_CONTROL) to read the UVC error code. On a device that is already stalling, this second transfer pushes the firmware into a full lockup. Introduce UVC_QUIRK_CTRL_THROTTLE (0x00080000) to address both issues: - Enforce a minimum 50ms interval between SET_CUR control transfers, preventing the rapid-fire pattern that overwhelms the firmware. 50ms allows up to 20 control changes per second, which is sufficient for interactive slider adjustments while keeping the device stable. - Skip the UVC_VC_REQUEST_ERROR_CODE_CONTROL query after EPIPE errors on devices with this quirk. EPIPE is returned directly without the follow-up query that would amplify the failure. The UVC control path is serialized by ctrl_mutex, so last_ctrl_set_jiffies does not require additional locking. Cc: stable@vger.kernel.org Signed-off-by: JP Hein <jp@jphein.com> --- drivers/media/usb/uvc/uvc_video.c | 32 +++++++++++++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 3 +++ 2 files changed, 35 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index 40c76c051..9f402f55e 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -75,8 +75,30 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, u8 error; u8 tmp; + /* + * Rate-limit SET_CUR operations for devices with fragile firmware. + * The Razer Kiyo Pro locks up under sustained rapid SET_CUR + * transfers (hundreds without delay), crashing the xHCI controller. + */ + if (query == UVC_SET_CUR && + (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)) { + unsigned long min_interval = msecs_to_jiffies(50); + + if (dev->last_ctrl_set_jiffies && + time_before(jiffies, + dev->last_ctrl_set_jiffies + min_interval)) { + unsigned long elapsed = dev->last_ctrl_set_jiffies + + min_interval - jiffies; + msleep(jiffies_to_msecs(elapsed)); + } + } + ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size, UVC_CTRL_CONTROL_TIMEOUT); + + if (query == UVC_SET_CUR && + (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)) + dev->last_ctrl_set_jiffies = jiffies; if (likely(ret == size)) return 0; @@ -108,6 +130,16 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, return ret < 0 ? ret : -EPIPE; } + /* + * Skip the error code query for devices that crash under load. + * The standard error-code query (GET_CUR on + * UVC_VC_REQUEST_ERROR_CODE_CONTROL) sends a second USB transfer to + * a device that is already stalling, which can amplify the failure + * into a full firmware lockup and xHCI controller death. + */ + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) + return -EPIPE; + /* Reuse data[0] to request the error code. */ tmp = *(u8 *)data; diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index 8480d65ec..cafc71457 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -81,6 +81,7 @@ #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000 #define UVC_QUIRK_MJPEG_NO_EOF 0x00020000 #define UVC_QUIRK_MSXU_META 0x00040000 +#define UVC_QUIRK_CTRL_THROTTLE 0x00080000 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x00000001 @@ -579,6 +580,8 @@ struct uvc_device { struct usb_interface *intf; unsigned long warnings; u32 quirks; + /* Control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */ + unsigned long last_ctrl_set_jiffies; int intfnum; char name[32]; -- 2.43.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-03-31 0:38 ` [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware JP Hein @ 2026-04-09 6:45 ` Ricardo Ribalda [not found] ` <CAD5VvzAu8+Qz7hEEBzuKvO11X=YD-wrtX3_Tk77g2Cq5rZZD0Q@mail.gmail.com> 2026-04-09 8:02 ` Michal Pecio 0 siblings, 2 replies; 30+ messages in thread From: Ricardo Ribalda @ 2026-04-09 6:45 UTC (permalink / raw) To: JP Hein, Alan Stern, Michal Pecio Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable Hi JP On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote: > > Some USB webcams have firmware that crashes when it receives rapid > consecutive UVC control transfers (SET_CUR). The Razer Kiyo Pro > (1532:0e05) is one such device -- after several hundred rapid control > changes over a few seconds, the device stops responding entirely, > triggering an xHCI stop-endpoint command timeout that causes the host > controller to be declared dead, disconnecting every USB device on the > bus. A usb device shall not be able crash the whole USB host. I believe that you already captured some logs and the USB guys are looking into it. I'd really like to hear what they have to say after reviewing them. > > The failure is amplified by the standard UVC error-code query: when a > SET_CUR fails with EPIPE, the driver sends a second transfer (GET_CUR > on UVC_VC_REQUEST_ERROR_CODE_CONTROL) to read the UVC error code. On a > device that is already stalling, this second transfer pushes the > firmware into a full lockup. > > Introduce UVC_QUIRK_CTRL_THROTTLE (0x00080000) to address both issues: > > - Enforce a minimum 50ms interval between SET_CUR control transfers, > preventing the rapid-fire pattern that overwhelms the firmware. > 50ms allows up to 20 control changes per second, which is sufficient > for interactive slider adjustments while keeping the device stable. > > - Skip the UVC_VC_REQUEST_ERROR_CODE_CONTROL query after EPIPE errors > on devices with this quirk. EPIPE is returned directly without the > follow-up query that would amplify the failure. > > The UVC control path is serialized by ctrl_mutex, so last_ctrl_set_jiffies > does not require additional locking. > > Cc: stable@vger.kernel.org > Signed-off-by: JP Hein <jp@jphein.com> > --- > drivers/media/usb/uvc/uvc_video.c | 32 +++++++++++++++++++++++++++++++ > drivers/media/usb/uvc/uvcvideo.h | 3 +++ > 2 files changed, 35 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index 40c76c051..9f402f55e 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -75,8 +75,30 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, > u8 error; > u8 tmp; > Why don't do you do the rate-limit in __uvc_query_ctrl()? Are you sure that you only have to limit UVC_SET_CUR? > + /* > + * Rate-limit SET_CUR operations for devices with fragile firmware. > + * The Razer Kiyo Pro locks up under sustained rapid SET_CUR > + * transfers (hundreds without delay), crashing the xHCI controller. > + */ > + if (query == UVC_SET_CUR && > + (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)) { > + unsigned long min_interval = msecs_to_jiffies(50); > + > + if (dev->last_ctrl_set_jiffies && > + time_before(jiffies, > + dev->last_ctrl_set_jiffies + min_interval)) { > + unsigned long elapsed = dev->last_ctrl_set_jiffies + > + min_interval - jiffies; > + msleep(jiffies_to_msecs(elapsed)); > + } > + } > + > ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size, > UVC_CTRL_CONTROL_TIMEOUT); > + > + if (query == UVC_SET_CUR && > + (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)) > + dev->last_ctrl_set_jiffies = jiffies; > if (likely(ret == size)) > return 0; > > @@ -108,6 +130,16 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, > return ret < 0 ? ret : -EPIPE; > } > > + /* > + * Skip the error code query for devices that crash under load. > + * The standard error-code query (GET_CUR on > + * UVC_VC_REQUEST_ERROR_CODE_CONTROL) sends a second USB transfer to > + * a device that is already stalling, which can amplify the failure > + * into a full firmware lockup and xHCI controller death. > + */ > + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) > + return -EPIPE; > + > /* Reuse data[0] to request the error code. */ > tmp = *(u8 *)data; > > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h > index 8480d65ec..cafc71457 100644 > --- a/drivers/media/usb/uvc/uvcvideo.h > +++ b/drivers/media/usb/uvc/uvcvideo.h > @@ -81,6 +81,7 @@ > #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000 > #define UVC_QUIRK_MJPEG_NO_EOF 0x00020000 > #define UVC_QUIRK_MSXU_META 0x00040000 > +#define UVC_QUIRK_CTRL_THROTTLE 0x00080000 > > /* Format flags */ > #define UVC_FMT_FLAG_COMPRESSED 0x00000001 > @@ -579,6 +580,8 @@ struct uvc_device { > struct usb_interface *intf; > unsigned long warnings; > u32 quirks; > + /* Control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */ > + unsigned long last_ctrl_set_jiffies; > int intfnum; > char name[32]; > > -- > 2.43.0 > -- Ricardo Ribalda ^ permalink raw reply [flat|nested] 30+ messages in thread
[parent not found: <CAD5VvzAu8+Qz7hEEBzuKvO11X=YD-wrtX3_Tk77g2Cq5rZZD0Q@mail.gmail.com>]
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware [not found] ` <CAD5VvzAu8+Qz7hEEBzuKvO11X=YD-wrtX3_Tk77g2Cq5rZZD0Q@mail.gmail.com> @ 2026-04-09 7:51 ` Jeffrey Hein 0 siblings, 0 replies; 30+ messages in thread From: Jeffrey Hein @ 2026-04-09 7:51 UTC (permalink / raw) To: Ricardo Ribalda Cc: Alan Stern, Michal Pecio, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable Hi Ricardo, On Thu, 9 Apr 2026 at 08:45, Ricardo Ribalda <ribalda@chromium.org> wrote: > A usb device shall not be able crash the whole USB host. I believe > that you already captured some logs and the USB guys are looking into > it. I'd really like to hear what they have to say after reviewing > them. Agreed -- a single device shouldn't be able to take down the host. Alan Stern raised the same point and asked whether xhci-hcd should handle this. Michal Pecio noted that the stop-endpoint command timeout is a controller-side failure and asked for dynamic debug traces on newer kernels and non-Intel hardware. I provided the 6.17 traces. The result: the stress test (control transfers only) now passes 50/50 thanks to xHCI error handling improvements between 6.8 and 6.17. But starting a video stream still triggers hc_died() -- the firmware fails to disable LPM during stream setup, the endpoint stalls, and the stop-endpoint command times out. So there's an open question on the xHCI side about whether the controller could recover from stop-endpoint timeouts instead of killing the HC. The UVC quirks are defense-in-depth -- they prevent the firmware from reaching the failure state that triggers the timeout in the first place. I'm also planning to test on additional Intel machines (and non-Intel if I can source one) to determine whether the stop-endpoint timeout is controller-specific, per Michal's request. > Why don't do you do the rate-limit in __uvc_query_ctrl()? Good point -- moved it there in v6. This covers all callers including uvc_set_video_ctrl() which bypasses uvc_query_ctrl() for probe/commit. > Are you sure that you only have to limit UVC_SET_CUR? I haven't been able to isolate the crash to a specific query direction -- our testing shows it's the sustained transfer rate that matters. v6 throttles all query types in __uvc_query_ctrl() to be safe. v6 posted with these changes. Thanks, JP > > On Wed, Apr 8, 2026 at 11:45 PM Ricardo Ribalda <ribalda@chromium.org> wrote: >> >> Hi JP >> >> On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote: >> > >> > Some USB webcams have firmware that crashes when it receives rapid >> > consecutive UVC control transfers (SET_CUR). The Razer Kiyo Pro >> > (1532:0e05) is one such device -- after several hundred rapid control >> > changes over a few seconds, the device stops responding entirely, >> > triggering an xHCI stop-endpoint command timeout that causes the host >> > controller to be declared dead, disconnecting every USB device on the >> > bus. >> >> A usb device shall not be able crash the whole USB host. I believe >> that you already captured some logs and the USB guys are looking into >> it. I'd really like to hear what they have to say after reviewing >> them. >> >> > >> > The failure is amplified by the standard UVC error-code query: when a >> > SET_CUR fails with EPIPE, the driver sends a second transfer (GET_CUR >> > on UVC_VC_REQUEST_ERROR_CODE_CONTROL) to read the UVC error code. On a >> > device that is already stalling, this second transfer pushes the >> > firmware into a full lockup. >> > >> > Introduce UVC_QUIRK_CTRL_THROTTLE (0x00080000) to address both issues: >> > >> > - Enforce a minimum 50ms interval between SET_CUR control transfers, >> > preventing the rapid-fire pattern that overwhelms the firmware. >> > 50ms allows up to 20 control changes per second, which is sufficient >> > for interactive slider adjustments while keeping the device stable. >> > >> > - Skip the UVC_VC_REQUEST_ERROR_CODE_CONTROL query after EPIPE errors >> > on devices with this quirk. EPIPE is returned directly without the >> > follow-up query that would amplify the failure. >> > >> > The UVC control path is serialized by ctrl_mutex, so last_ctrl_set_jiffies >> > does not require additional locking. >> > >> > Cc: stable@vger.kernel.org >> > Signed-off-by: JP Hein <jp@jphein.com> >> > --- >> > drivers/media/usb/uvc/uvc_video.c | 32 +++++++++++++++++++++++++++++++ >> > drivers/media/usb/uvc/uvcvideo.h | 3 +++ >> > 2 files changed, 35 insertions(+) >> > >> > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c >> > index 40c76c051..9f402f55e 100644 >> > --- a/drivers/media/usb/uvc/uvc_video.c >> > +++ b/drivers/media/usb/uvc/uvc_video.c >> > @@ -75,8 +75,30 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, >> > u8 error; >> > u8 tmp; >> > >> >> Why don't do you do the rate-limit in __uvc_query_ctrl()? >> >> Are you sure that you only have to limit UVC_SET_CUR? >> >> > + /* >> > + * Rate-limit SET_CUR operations for devices with fragile firmware. >> > + * The Razer Kiyo Pro locks up under sustained rapid SET_CUR >> > + * transfers (hundreds without delay), crashing the xHCI controller. >> > + */ >> > + if (query == UVC_SET_CUR && >> > + (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)) { >> > + unsigned long min_interval = msecs_to_jiffies(50); >> > + >> > + if (dev->last_ctrl_set_jiffies && >> > + time_before(jiffies, >> > + dev->last_ctrl_set_jiffies + min_interval)) { >> > + unsigned long elapsed = dev->last_ctrl_set_jiffies + >> > + min_interval - jiffies; >> > + msleep(jiffies_to_msecs(elapsed)); >> > + } >> > + } >> > + >> > ret = __uvc_query_ctrl(dev, query, unit, intfnum, cs, data, size, >> > UVC_CTRL_CONTROL_TIMEOUT); >> > + >> > + if (query == UVC_SET_CUR && >> > + (dev->quirks & UVC_QUIRK_CTRL_THROTTLE)) >> > + dev->last_ctrl_set_jiffies = jiffies; >> > if (likely(ret == size)) >> > return 0; >> > >> > @@ -108,6 +130,16 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, >> > return ret < 0 ? ret : -EPIPE; >> > } >> > >> > + /* >> > + * Skip the error code query for devices that crash under load. >> > + * The standard error-code query (GET_CUR on >> > + * UVC_VC_REQUEST_ERROR_CODE_CONTROL) sends a second USB transfer to >> > + * a device that is already stalling, which can amplify the failure >> > + * into a full firmware lockup and xHCI controller death. >> > + */ >> > + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) >> > + return -EPIPE; >> > + >> > /* Reuse data[0] to request the error code. */ >> > tmp = *(u8 *)data; >> > >> > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h >> > index 8480d65ec..cafc71457 100644 >> > --- a/drivers/media/usb/uvc/uvcvideo.h >> > +++ b/drivers/media/usb/uvc/uvcvideo.h >> > @@ -81,6 +81,7 @@ >> > #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000 >> > #define UVC_QUIRK_MJPEG_NO_EOF 0x00020000 >> > #define UVC_QUIRK_MSXU_META 0x00040000 >> > +#define UVC_QUIRK_CTRL_THROTTLE 0x00080000 >> > >> > /* Format flags */ >> > #define UVC_FMT_FLAG_COMPRESSED 0x00000001 >> > @@ -579,6 +580,8 @@ struct uvc_device { >> > struct usb_interface *intf; >> > unsigned long warnings; >> > u32 quirks; >> > + /* Control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */ >> > + unsigned long last_ctrl_set_jiffies; >> > int intfnum; >> > char name[32]; >> > >> > -- >> > 2.43.0 >> > >> >> >> -- >> Ricardo Ribalda ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-09 6:45 ` Ricardo Ribalda [not found] ` <CAD5VvzAu8+Qz7hEEBzuKvO11X=YD-wrtX3_Tk77g2Cq5rZZD0Q@mail.gmail.com> @ 2026-04-09 8:02 ` Michal Pecio 2026-04-09 8:15 ` Jeffrey Hein 2026-04-09 20:17 ` Michal Pecio 1 sibling, 2 replies; 30+ messages in thread From: Michal Pecio @ 2026-04-09 8:02 UTC (permalink / raw) To: Ricardo Ribalda Cc: JP Hein, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote: > Hi JP > > On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote: > > > > Some USB webcams have firmware that crashes when it receives rapid > > consecutive UVC control transfers (SET_CUR). The Razer Kiyo Pro > > (1532:0e05) is one such device -- after several hundred rapid > > control changes over a few seconds, the device stops responding > > entirely, triggering an xHCI stop-endpoint command timeout that > > causes the host controller to be declared dead, disconnecting every > > USB device on the bus. > > A usb device shall not be able crash the whole USB host. I believe > that you already captured some logs and the USB guys are looking into > it. I'd really like to hear what they have to say after reviewing > them. Sorry, I forgot about this bug. I will take a closer look at logs later today. I see that there is a case which crashes the host controller, but without dynamic debug. It would be helpful if this can be reproduced with debug enabled. In the future, please also make sure that there are no unrelated devices spamming dmesg, like "slot 17 ep 2" in those "stall" logs. Please find this device and disconnect it or unbind its driver. The initial cause of all that may really be the device getting locked up for no good reason, but not 100% sure yet. Regards, Michal ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-09 8:02 ` Michal Pecio @ 2026-04-09 8:15 ` Jeffrey Hein 2026-04-09 20:17 ` Michal Pecio 1 sibling, 0 replies; 30+ messages in thread From: Jeffrey Hein @ 2026-04-09 8:15 UTC (permalink / raw) To: Michal Pecio Cc: Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable Hi Michal, Thanks for taking another look. I will reproduce the hc_died() crash with dynamic debug enabled (xhci_hcd +p, usbcore +p) and with all unrelated USB devices disconnected so the logs are clean. The slot 17 stalls in the previous logs may have been from another device on the bus -- I will make sure only the Kiyo is connected for the next capture. The crash that kills the controller happens when starting a video stream (LPM disable failure path). I can SSH in to grab dmesg live during the crash since the controller death only takes out USB, not the network. Will follow up with the traces. Thanks, JP On Thu, Apr 9, 2026 at 1:02 AM Michal Pecio <michal.pecio@gmail.com> wrote: > > On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote: > > Hi JP > > > > On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote: > > > > > > Some USB webcams have firmware that crashes when it receives rapid > > > consecutive UVC control transfers (SET_CUR). The Razer Kiyo Pro > > > (1532:0e05) is one such device -- after several hundred rapid > > > control changes over a few seconds, the device stops responding > > > entirely, triggering an xHCI stop-endpoint command timeout that > > > causes the host controller to be declared dead, disconnecting every > > > USB device on the bus. > > > > A usb device shall not be able crash the whole USB host. I believe > > that you already captured some logs and the USB guys are looking into > > it. I'd really like to hear what they have to say after reviewing > > them. > > Sorry, I forgot about this bug. I will take a closer look at logs > later today. > > I see that there is a case which crashes the host controller, but > without dynamic debug. It would be helpful if this can be reproduced > with debug enabled. > > In the future, please also make sure that there are no unrelated > devices spamming dmesg, like "slot 17 ep 2" in those "stall" logs. > Please find this device and disconnect it or unbind its driver. > > The initial cause of all that may really be the device getting > locked up for no good reason, but not 100% sure yet. > > Regards, > Michal ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-09 8:02 ` Michal Pecio 2026-04-09 8:15 ` Jeffrey Hein @ 2026-04-09 20:17 ` Michal Pecio 2026-04-10 0:01 ` Jeffrey Hein 2026-04-10 21:48 ` Mathias Nyman 1 sibling, 2 replies; 30+ messages in thread From: Michal Pecio @ 2026-04-09 20:17 UTC (permalink / raw) To: Ricardo Ribalda Cc: JP Hein, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable On Thu, 9 Apr 2026 10:02:47 +0200, Michal Pecio wrote: > On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote: > > A usb device shall not be able crash the whole USB host. I believe > > that you already captured some logs and the USB guys are looking > > into it. I'd really like to hear what they have to say after > > reviewing them. > > Sorry, I forgot about this bug. I will take a closer look at logs > later today. lsusb -v of identical(?) device is found here: http://linux-hardware.org/?probe=a1cd74d9ac&log=lsusb And I'm looking at the logs here: https://github.com/jphein/kiyo-xhci-fix/tree/main/kernel-patches/crash-evidence crash-6.17-stock-stress-20260330.log Empty file, not sure why included at all. crash-6.17-video-call-20260330.log No debug messages. At some point: Mar 30 10:00:52 katana kernel: usb 2-3.4: disable of device-initiated U1 failed. Mar 30 10:00:53 katana kernel: usb 2-3.4: Failed to set U2 timeout to 0x0,error code -110 Mar 30 10:00:53 katana kernel: uvcvideo 2-3.4:1.1: usb_set_interface Failed to disable LPM Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1). Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1). Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1). Not sure if the LPM thing is the cause or a symptom of general EP 0 disfunction, as seen in subsequent EPROTO errors. Not sure why usb_set_interface() is called. Is this the start streaming case mentioned in some email? What was happening before? stall-6.17-stock-no-workarounds-20260330.log All sorts of repeating errors, including stall on EP1IN ("ep 2") which is supposedly isochronous and shouldn't. Clearly some broken state, not sure how things got there. stall-6.17-stress-during-call-20260330.log This is the most interesting one. The first slightly unusual thing is repeated unlinks on EP5IN (int), not sure why uvcvideo would do that, possibly result of the stess test. I know that such pattern alone can break ASMedia host controllers for no reason I understand, though this one is Intel. It's suspicious that wBytesPerInterval of the endpoint is 8, wMaxPacket is 64 and URBs are 16 bytes. Just in case, I attach a test patch which rises wBytesPerInterval to match wMaxPacketSize. The first definite anomaly is Transaction Error on EP5IN: Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Transfer error for slot 18 ep 10 on endpoint Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Hard-reset ep 10, slot 18 Not sure why endpoint reset follows immediately without retries. The test patch also removes one potential reason. We might see whether the retries will fail, or if retrying until the transfer succeeds magically prevents the subsequent disaster. Perhaps the device gets unusually upset about sequence mismatch on this endpoint, which results from not clearing this halt condition properly (known problem). Five seconds later two control URBs are unlinked: Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 00000000122aa5e2, dev 3.1, ep 0x0, starting at offset 0x11e227b40 Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: // Ding dong! Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 000000008a55bcd3, dev 3.1, ep 0x0, starting at offset 0x11e227b20 Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Not queuing Stop Endpoint on slot 18 ep 0 in state 0x44 Probably timeout, i.e. things got stuck. Oddly, state 0x44 indicates that this control endpoint has previously halted - error or stall. Higher layers notice that things are timing out: Mar 30 16:59:21 katana kernel: usb 2-3.1: pipewire timed out on ep0out len=0/0 Mar 30 16:59:21 katana kernel: usb 2-3.1: disable of device-initiated U1 failed. Mar 30 16:59:21 katana kernel: usb 2-3.1: ThreadPoolSingl timed out on ep0out len=0/1 Nothing works from now. At some point the parent hub reports disconnection and reconnection. Still nothing works. --- Would it be possible to repeat this test with the patch below? It overrides the suspicious wBytesPerInterval and hopefully enables retries of this failed interrupt URB. We will see what happens. xhci-mem.c b/drivers/usb/host/xhci-mem.c index 1d50c91afd7f..17d78b4e07bf 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1464,6 +1464,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci, mult = xhci_get_endpoint_mult(xhci, udev, ep); max_packet = xhci_usb_endpoint_maxp(udev, ep); max_burst = xhci_get_endpoint_max_burst(udev, ep); + if (interval && max_esit_payload < max_packet) { + xhci_err(xhci, "max_esit_payload %d -> %d\n", max_esit_payload, max_packet); + max_esit_payload = max_packet; + } avg_trb_len = max_esit_payload; /* FIXME dig Mult and streams info out of ep companion desc */ diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 98ef014c8dee..e5823650850a 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2544,6 +2544,7 @@ static void process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, td->status = 0; break; case COMP_SHORT_PACKET: + ep->err_count = 0; td->status = 0; break; case COMP_STOPPED_SHORT_PACKET: ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-09 20:17 ` Michal Pecio @ 2026-04-10 0:01 ` Jeffrey Hein 2026-04-10 0:24 ` Jeffrey Hein 2026-04-10 21:48 ` Mathias Nyman 1 sibling, 1 reply; 30+ messages in thread From: Jeffrey Hein @ 2026-04-10 0:01 UTC (permalink / raw) To: Michal Pecio Cc: Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable Hi Michal, Thanks for the detailed analysis. > crash-6.17-stock-stress-20260330.log > Empty file, not sure why included at all. Sorry about that -- removed. > Not sure why usb_set_interface() is called. Is this the start > streaming case mentioned in some email? What was happening before? Yes, this is the start-streaming path. The app (Google Meet via browser) opens the video device, which triggers usb_set_interface() to select the alt setting for the isochronous endpoint. The LPM disable failure happens during that transition. > It's suspicious that wBytesPerInterval of the endpoint is 8, > wMaxPacket is 64 and URBs are 16 bytes. Interesting find. I had not looked at the interrupt endpoint descriptors closely. > Would it be possible to repeat this test with the patch below? Absolutely. I will apply your patch, rebuild xhci-hcd, reproduce the crash with dynamic debug enabled (xhci_hcd +p, usbcore +p), only the Kiyo connected, and grab dmesg via SSH during the crash. The CI bot flagged a dts-bindings failure on v6 but all code checks (compile, smatch, sparse, checkpatch) passed -- unrelated to the UVC patches. Will follow up with traces. Thanks, JP On Thu, Apr 9, 2026 at 1:17 PM Michal Pecio <michal.pecio@gmail.com> wrote: > > On Thu, 9 Apr 2026 10:02:47 +0200, Michal Pecio wrote: > > On Thu, 9 Apr 2026 08:45:17 +0200, Ricardo Ribalda wrote: > > > A usb device shall not be able crash the whole USB host. I believe > > > that you already captured some logs and the USB guys are looking > > > into it. I'd really like to hear what they have to say after > > > reviewing them. > > > > Sorry, I forgot about this bug. I will take a closer look at logs > > later today. > > lsusb -v of identical(?) device is found here: > http://linux-hardware.org/?probe=a1cd74d9ac&log=lsusb > > And I'm looking at the logs here: > https://github.com/jphein/kiyo-xhci-fix/tree/main/kernel-patches/crash-evidence > > crash-6.17-stock-stress-20260330.log > Empty file, not sure why included at all. > > crash-6.17-video-call-20260330.log > No debug messages. At some point: > Mar 30 10:00:52 katana kernel: usb 2-3.4: disable of device-initiated U1 failed. > Mar 30 10:00:53 katana kernel: usb 2-3.4: Failed to set U2 timeout to 0x0,error code -110 > Mar 30 10:00:53 katana kernel: uvcvideo 2-3.4:1.1: usb_set_interface Failed to disable LPM > Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1). > Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1). > Mar 30 10:00:54 katana kernel: usb 2-3.4: Failed to query (SET_CUR) UVC control 11 on unit 3: -71 (exp. 1). > > Not sure if the LPM thing is the cause or a symptom of general EP 0 > disfunction, as seen in subsequent EPROTO errors. > > Not sure why usb_set_interface() is called. Is this the start streaming > case mentioned in some email? What was happening before? > > stall-6.17-stock-no-workarounds-20260330.log > All sorts of repeating errors, including stall on EP1IN ("ep 2") which > is supposedly isochronous and shouldn't. Clearly some broken state, not > sure how things got there. > > stall-6.17-stress-during-call-20260330.log > This is the most interesting one. > > The first slightly unusual thing is repeated unlinks on EP5IN (int), > not sure why uvcvideo would do that, possibly result of the stess test. > I know that such pattern alone can break ASMedia host controllers for > no reason I understand, though this one is Intel. > > It's suspicious that wBytesPerInterval of the endpoint is 8, wMaxPacket > is 64 and URBs are 16 bytes. Just in case, I attach a test patch which > rises wBytesPerInterval to match wMaxPacketSize. > > The first definite anomaly is Transaction Error on EP5IN: > Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Transfer error for slot 18 ep 10 on endpoint > Mar 30 16:59:16 katana kernel: xhci_hcd 0000:00:14.0: Hard-reset ep 10, slot 18 > > Not sure why endpoint reset follows immediately without retries. > The test patch also removes one potential reason. We might see whether > the retries will fail, or if retrying until the transfer succeeds > magically prevents the subsequent disaster. Perhaps the device gets > unusually upset about sequence mismatch on this endpoint, which results > from not clearing this halt condition properly (known problem). > > Five seconds later two control URBs are unlinked: > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 00000000122aa5e2, dev 3.1, ep 0x0, starting at offset 0x11e227b40 > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: // Ding dong! > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 000000008a55bcd3, dev 3.1, ep 0x0, starting at offset 0x11e227b20 > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Not queuing Stop Endpoint on slot 18 ep 0 in state 0x44 > > Probably timeout, i.e. things got stuck. Oddly, state 0x44 indicates > that this control endpoint has previously halted - error or stall. > > Higher layers notice that things are timing out: > > Mar 30 16:59:21 katana kernel: usb 2-3.1: pipewire timed out on ep0out len=0/0 > Mar 30 16:59:21 katana kernel: usb 2-3.1: disable of device-initiated U1 failed. > Mar 30 16:59:21 katana kernel: usb 2-3.1: ThreadPoolSingl timed out on ep0out len=0/1 > > Nothing works from now. At some point the parent hub reports > disconnection and reconnection. Still nothing works. > > --- > > Would it be possible to repeat this test with the patch below? > It overrides the suspicious wBytesPerInterval and hopefully enables > retries of this failed interrupt URB. We will see what happens. > > xhci-mem.c b/drivers/usb/host/xhci-mem.c > index 1d50c91afd7f..17d78b4e07bf 100644 > --- a/drivers/usb/host/xhci-mem.c > +++ b/drivers/usb/host/xhci-mem.c > @@ -1464,6 +1464,10 @@ int xhci_endpoint_init(struct xhci_hcd *xhci, > mult = xhci_get_endpoint_mult(xhci, udev, ep); > max_packet = xhci_usb_endpoint_maxp(udev, ep); > max_burst = xhci_get_endpoint_max_burst(udev, ep); > + if (interval && max_esit_payload < max_packet) { > + xhci_err(xhci, "max_esit_payload %d -> %d\n", max_esit_payload, max_packet); > + max_esit_payload = max_packet; > + } > avg_trb_len = max_esit_payload; > > /* FIXME dig Mult and streams info out of ep companion desc */ > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c > index 98ef014c8dee..e5823650850a 100644 > --- a/drivers/usb/host/xhci-ring.c > +++ b/drivers/usb/host/xhci-ring.c > @@ -2544,6 +2544,7 @@ static void process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, > td->status = 0; > break; > case COMP_SHORT_PACKET: > + ep->err_count = 0; > td->status = 0; > break; > case COMP_STOPPED_SHORT_PACKET: > > > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-10 0:01 ` Jeffrey Hein @ 2026-04-10 0:24 ` Jeffrey Hein 2026-04-10 4:47 ` Michal Pecio 0 siblings, 1 reply; 30+ messages in thread From: Jeffrey Hein @ 2026-04-10 0:24 UTC (permalink / raw) To: Michal Pecio Cc: Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable One more thing -- you mentioned referencing an lsusb from linux-hardware.org for an "identical(?) device". Here is the actual lsusb -vv from our device, confirming the wBytesPerInterval mismatch you found. EP5 IN (interrupt) from raw SS Endpoint Companion descriptor: Endpoint Descriptor: bEndpointAddress 0x85 EP 5 IN bmAttributes 3 (Interrupt) wMaxPacketSize 0x0040 1x 64 bytes bInterval 8 SS Endpoint Companion: bMaxBurst 0 bmAttributes 0x00 wBytesPerInterval 8 So wBytesPerInterval (8) is indeed 8x smaller than wMaxPacketSize (64), matching what you saw in the third-party listing. Note that lsusb -vv does not decode wBytesPerInterval for this endpoint -- the value above was parsed from the raw descriptor bytes in sysfs. The full lsusb -vv (934 lines) is now in the repo: https://github.com/jphein/kiyo-xhci-fix/blob/main/kernel-patches/crash-evidence/lsusb-vv-kiyo-pro.txt I will follow up with the test results from your patch. JP ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-10 0:24 ` Jeffrey Hein @ 2026-04-10 4:47 ` Michal Pecio 0 siblings, 0 replies; 30+ messages in thread From: Michal Pecio @ 2026-04-10 4:47 UTC (permalink / raw) To: Jeffrey Hein Cc: Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable On Thu, 9 Apr 2026 17:24:36 -0700, Jeffrey Hein wrote: > So wBytesPerInterval (8) is indeed 8x smaller than wMaxPacketSize > (64), matching what you saw in the third-party listing. Technically it's a spec violation if a device claims 8 bytes but respons with a single packet larger than that to a 16 byte (or any other) URB. Though no problems were known to result until last month. It seems most host controllers ignore byte per interval on interrupt. > Note that lsusb -vv does not decode wBytesPerInterval for this > endpoint -- the value above was parsed from the raw descriptor bytes > in sysfs. The full lsusb -vv (934 lines) is now in the repo: It does decode it, but you need the latest usbutils version 019. And there should be no need for lsusb -vv, just lsusb -v. I think the output pasted into v6 patch was truncated. Regards, Michal ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-09 20:17 ` Michal Pecio 2026-04-10 0:01 ` Jeffrey Hein @ 2026-04-10 21:48 ` Mathias Nyman 2026-04-10 23:06 ` Jeffrey Hein 2026-04-11 13:39 ` Michal Pecio 1 sibling, 2 replies; 30+ messages in thread From: Mathias Nyman @ 2026-04-10 21:48 UTC (permalink / raw) To: Michal Pecio, Ricardo Ribalda Cc: JP Hein, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable On 4/9/26 23:17, Michal Pecio wrote: > Five seconds later two control URBs are unlinked: > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 00000000122aa5e2, dev 3.1, ep 0x0, starting at offset 0x11e227b40 > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: // Ding dong! > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 000000008a55bcd3, dev 3.1, ep 0x0, starting at offset 0x11e227b20 > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Not queuing Stop Endpoint on slot 18 ep 0 in state 0x44 log continues with: Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x11e227b40 (dma) in stream 0 URB 00000000122aa5e2 Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x11e227b20 (dma) in stream 0 URB 000000008a55bcd3 Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Set TR Deq ptr 0x11e227b40, cycle 0 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). xhci spec section 4.8.3 'Endpoint context state' additional Note states that: "The Default Control Endpoint shall return to the Running state when the Doorbell is rung for the next Setup Stage TD sent to the endpoint." Here the dequeue pointer will still be on the no-op TRB after queuing a new control transfer after it. Not on a setup stage TRB This can happen when we cancel two control URBs at the same time. We turn the second URB TRBs starting at 0x11e227b40 into no-ops, then move past the first URB TRBs starting at 0x11e227b20 to the second URB no-op TRB at 0x11e227b40. It's possible that disabling LPM helps as it reduces the number of control transfers, so there is a much smaller risk of cancelling two control URBs in one go. Thanks Mathias ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-10 21:48 ` Mathias Nyman @ 2026-04-10 23:06 ` Jeffrey Hein 2026-04-13 8:05 ` Michal Pecio 2026-04-13 20:24 ` Michal Pecio 2026-04-11 13:39 ` Michal Pecio 1 sibling, 2 replies; 30+ messages in thread From: Jeffrey Hein @ 2026-04-10 23:06 UTC (permalink / raw) To: Mathias Nyman, Michal Pecio, Ricardo Ribalda Cc: Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-10 23:06 ` Jeffrey Hein @ 2026-04-13 8:05 ` Michal Pecio 2026-04-13 20:24 ` Michal Pecio 1 sibling, 0 replies; 30+ messages in thread From: Michal Pecio @ 2026-04-13 8:05 UTC (permalink / raw) To: Jeffrey Hein Cc: Mathias Nyman, Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable On Fri, 10 Apr 2026 16:06:43 -0700, Jeffrey Hein wrote: > 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 That's not abnormal and it probably shouldn't be logged at all. I filtered out some of this noise from subsequent log snippets. This is interesting because it shows the isochronous video endpoint being enabled and then stopped and removed shortly after: [Fri Apr 10 15:26:04 2026] xhci_hcd 0000:00:14.0: add ep 0x81, slot id 5, new drop flags = 0x0, new add flags = 0x8 [Fri Apr 10 15:26:04 2026] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 00000000921e7e25 [Fri Apr 10 15:26:04 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:26:04 2026] xhci_hcd 0000:00:14.0: Successful Endpoint Configure command [Fri Apr 10 15:26:05 2026] xhci_hcd 0000:00:14.0: Cancel URB 0000000009b97440, dev 3.1, ep 0x81, starting at offset 0x2db0885f0 [Fri Apr 10 15:26:05 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:26:05 2026] xhci_hcd 0000:00:14.0: Stopped on Transfer TRB for slot 5 ep 2 [...] [Fri Apr 10 15:26:05 2026] xhci_hcd 0000:00:14.0: drop ep 0x81, slot id 5, new drop flags = 0x8, new add flags = 0x0 Then EP5IN submit/unlink cycles continue. And video starts again: [Fri Apr 10 15:26:09 2026] xhci_hcd 0000:00:14.0: add ep 0x81, slot id 5, new drop flags = 0x0, new add flags = 0x8 [Fri Apr 10 15:26:09 2026] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 00000000921e7e25 [Fri Apr 10 15:26:09 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:26:09 2026] xhci_hcd 0000:00:14.0: Successful Endpoint Configure command Transfer error followed by normal operation, seems harmless so far: [Fri Apr 10 15:29:04 2026] xhci_hcd 0000:00:14.0: Transfer error for slot 5 ep 2 on endpoint [Fri Apr 10 15:29:04 2026] xhci_hcd 0000:00:14.0: Error mid isoc TD, wait for final completion event [Fri Apr 10 15:29:04 2026] xhci_hcd 0000:00:14.0: Transfer error for slot 5 ep 2 on endpoint [Fri Apr 10 15:29:04 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fb7e0, comp_code 13 after 13 EP0 stall, not seen before. A bit suspicious, but video still runs: [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x00000002db088de0, comp_code 13 after 13 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x00000002db088e10, comp_code 13 after 13 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Stalled endpoint for slot 5 ep 0 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Hard-reset ep 0, slot 5 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x114a485c0 (dma) in stream 0 URB 000000000ffbecf4 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Set TR Deq ptr 0x114a485f0, cycle 0 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: xhci_giveback_invalidated_tds: Keep cancelled URB 000000000ffbecf4 TD as cancel_status is 2 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x00000002db088e40, comp_code 13 after 13 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @114a485f0 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: xhci_handle_cmd_set_deq: Giveback cancelled URB 000000000ffbecf4 TD [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Giveback URB 000000000ffbecf4, len = 0, expected = 4, status = -32 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: xhci_handle_cmd_set_deq: All TDs cleared, ring doorbell [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x00000002db088e80, comp_code 13 after 13 [Fri Apr 10 15:30:26 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x00000002db088eb0, comp_code 13 after 13 EP0 timeout and unlink, video endpoint fails shortly after: [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fbe30, comp_code 13 after 13 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fbe60, comp_code 13 after 13 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Cancel URB 0000000008ead041, dev 3.1, ep 0x0, starting at offset 0x114a48290 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Stopped on Transfer TRB for slot 5 ep 0 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x114a48290 (dma) in stream 0 URB 0000000008ead041 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Set TR Deq ptr 0x114a482c0, cycle 0 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: xhci_giveback_invalidated_tds: Keep cancelled URB 0000000008ead041 TD as cancel_status is 2 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @114a482c0 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: xhci_handle_cmd_set_deq: Giveback cancelled URB 0000000008ead041 TD [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Giveback URB 0000000008ead041, len = 2, expected = 2, status = -115 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: xhci_handle_cmd_set_deq: All TDs cleared, ring doorbell [Fri Apr 10 15:30:48 2026] usb 2-3.1: ThreadPoolSingl timed out on ep0in len=2/2 [Fri Apr 10 15:30:48 2026] usb 2-3.1: Failed to query (GET_CUR) UVC control 6 on unit 1: -110 (exp. 2). [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fbe90, comp_code 13 after 13 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fbec0, comp_code 13 after 13 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fbef0, comp_code 13 after 13 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fbf30, comp_code 13 after 13 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000028c6fbf60, comp_code 13 after 13 [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Transfer error for slot 5 ep 2 on endpoint [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Miss service interval error for slot 5 ep 2, set skip flag [Fri Apr 10 15:30:48 2026] xhci_hcd 0000:00:14.0: Miss service interval error for slot 5 ep 2, set skip flag Now things are properly broken. Next EP0 URB times out too: [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Cancel URB 000000008f70ed5c, dev 3.1, ep 0x0, starting at offset 0x114a482c0 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Set TR Deq ptr 0x114a482f0, cycle 0 [...] [Fri Apr 10 15:30:53 2026] usb 2-3.1: ThreadPoolSingl timed out on ep0in len=0/2 [Fri Apr 10 15:30:53 2026] usb 2-3.1: Failed to query (GET_CUR) UVC control 6 on unit 1: -110 (exp. 2). Fololwed by Transaction Error on the next and subsequent ones: [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Transfer error for slot 5 ep 0 on endpoint [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: TRB error 4, halted endpoint index = 0 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Hard-reset ep 0, slot 5 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Ignoring reset ep completion code of 1 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x114a482f0 (dma) in stream 0 URB 000000000ca6398c [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Set TR Deq ptr 0x114a48320, cycle 0 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: xhci_giveback_invalidated_tds: Keep cancelled URB 000000000ca6398c TD as cancel_status is 2 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Successful Set TR Deq Ptr cmd, deq = @114a48320 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: xhci_handle_cmd_set_deq: Giveback cancelled URB 000000000ca6398c TD [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: Giveback URB 000000000ca6398c, len = 0, expected = 2, status = -71 [Fri Apr 10 15:30:53 2026] xhci_hcd 0000:00:14.0: xhci_handle_cmd_set_deq: All TDs cleared, ring doorbell [Fri Apr 10 15:30:53 2026] usb 2-3.1: Failed to query (GET_CUR) UVC control 6 on unit 1: -71 (exp. 2). It seems the driver stopped resubmitting video URBs here and issued some control transfer. It timed out and unlinking crashed the HC. [Fri Apr 10 15:30:54 2026] xhci_hcd 0000:00:14.0: Miss service interval error for slot 5 ep 2, set skip flag [Fri Apr 10 15:30:54 2026] xhci_hcd 0000:00:14.0: Miss service interval error for slot 5 ep 2, set skip flag [Fri Apr 10 15:30:54 2026] xhci_hcd 0000:00:14.0: Overrun event on slot 5 ep 2 [Fri Apr 10 15:30:54 2026] xhci_hcd 0000:00:14.0: Skipped one TD for slot 5 ep 2 [Fri Apr 10 15:30:59 2026] xhci_hcd 0000:00:14.0: Cancel URB 000000007f4f069a, dev 3.1, ep 0x0, starting at offset 0x114a48770 [Fri Apr 10 15:30:59 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:31:04 2026] xhci_hcd 0000:00:14.0: Command timeout, USBSTS: 0x00000000 [Fri Apr 10 15:31:04 2026] xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command --- Question: can you kill it by starting some video application to set the camera up, closing it and then running this loop? while :; do v4l2-ctl -d /dev/video0 --stream-mmap --stream-count=1; done Regards, Michal ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-10 23:06 ` Jeffrey Hein 2026-04-13 8:05 ` Michal Pecio @ 2026-04-13 20:24 ` Michal Pecio 1 sibling, 0 replies; 30+ messages in thread From: Michal Pecio @ 2026-04-13 20:24 UTC (permalink / raw) To: Jeffrey Hein Cc: Mathias Nyman, Ricardo Ribalda, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable On Fri, 10 Apr 2026 16:06:43 -0700, Jeffrey Hein wrote: > 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. Something weird when video was being disabled: [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x0000000272e42200, comp_code 13 after 13 [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x0000000272e42230, comp_code 13 after 13 [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Cancel URB 0000000052d839d8, dev 3.1, ep 0x81, starting at offset 0x272e42f00 [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Stopped on Transfer TRB for slot 36 ep 2 [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x272e42f00 (dma) in stream 0 URB 0000000052d839d8 [...] [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: xhci_giveback_invalidated_tds: Giveback cancelled URB 0000000052d839d8 TD [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Cancel URB 00000000d8d84b58, dev 3.1, ep 0x81, starting at offset 0x260549210 [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Transfer error for slot 36 ep 2 on endpoint [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Stopped on Transfer TRB for slot 36 ep 2 [...] [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: drop ep 0x81, slot id 36, new drop flags = 0x8, new add flags = 0x0 Video started again, seemed to work for a while: [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: add ep 0x81, slot id 36, new drop flags = 0x0, new add flags = 0x8 [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 00000000e40f0c43 [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: Successful Endpoint Configure command [Fri Apr 10 15:44:47 2026] usb 2-3.1: Hub-initiated U1 disabled due to long timeout 16800us [Fri Apr 10 15:44:47 2026] usb 2-3.1: Hub-initiated U1 disabled due to long timeout 132us [Fri Apr 10 15:44:47 2026] usb 2-3.1: Hub-initiated U1 disabled due to long timeout 1050us [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: Set up evaluate context for LPM MEL change. [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: // Ding dong! [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: Successful evaluate context command [Fri Apr 10 15:44:47 2026] usb 2-3.1: Disable U2, ESIT shorter than exit latency [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x0000000260549020, comp_code 13 after 13 [Fri Apr 10 15:44:47 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x0000000260549050, comp_code 13 after 13 Until it broke, not sure what caused this. No EP5IN unlinks here. [Fri Apr 10 15:45:09 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x0000000272e42690, comp_code 13 after 13 [Fri Apr 10 15:45:09 2026] xhci_hcd 0000:00:14.0: Spurious event dma 0x0000000272e426d0, comp_code 13 after 13 [Fri Apr 10 15:45:09 2026] xhci_hcd 0000:00:14.0: No Ping response error for slot 36 ep 2, Skip one Isoc TD [Fri Apr 10 15:45:09 2026] xhci_hcd 0000:00:14.0: No Ping response error for slot 36 ep 2, Skip one Isoc TD [Fri Apr 10 15:45:09 2026] xhci_hcd 0000:00:14.0: No Ping response error for slot 36 ep 2, Skip one Isoc TD Then EP5IN also fails and is soft-retried, but it doesn't help. Control requests get EPROTO or ETIMEDOUT as usual. [Fri Apr 10 15:45:09 2026] xhci_hcd 0000:00:14.0: Transfer error for slot 36 ep 10 on endpoint [Fri Apr 10 15:45:09 2026] xhci_hcd 0000:00:14.0: Soft-reset ep 10, slot 36 Looks like the device is dead indeed, or the HC broke down and can't communiate with it. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware 2026-04-10 21:48 ` Mathias Nyman 2026-04-10 23:06 ` Jeffrey Hein @ 2026-04-11 13:39 ` Michal Pecio 1 sibling, 0 replies; 30+ messages in thread From: Michal Pecio @ 2026-04-11 13:39 UTC (permalink / raw) To: Mathias Nyman Cc: Ricardo Ribalda, JP Hein, Alan Stern, Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, stable On Sat, 11 Apr 2026 00:48:05 +0300, Mathias Nyman wrote: > > Five seconds later two control URBs are unlinked: > > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 00000000122aa5e2, dev 3.1, ep 0x0, starting at offset 0x11e227b40 > > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: // Ding dong! > > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Cancel URB 000000008a55bcd3, dev 3.1, ep 0x0, starting at offset 0x11e227b20 > > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Not queuing Stop Endpoint on slot 18 ep 0 in state 0x44 > > log continues with: > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x11e227b40 (dma) in stream 0 URB 00000000122aa5e2 > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Removing canceled TD starting at 0x11e227b20 (dma) in stream 0 URB 000000008a55bcd3 > Mar 30 16:59:21 katana kernel: xhci_hcd 0000:00:14.0: Set TR Deq ptr 0x11e227b40, cycle 0 > > 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 could explain why it doesn't work later, but not why these URBs have been unlinked after making no progress for 5 seconds. EP0 was probably still functioning normally during those submit-unlink cycles on 0x85 and there were no EP0 unlinks until these above. Another corner case which could potentially confuse HCs is Set TR Deq to a Link TRB, but it doesn't occur in this log on any endpoint. By the way, are you able to find out what this is? 198 falls into the "vendor defined error" range and vendor is Intel. crash-6.17.0-xhci-test-20260410-154243.log, isochronous URB unlink: [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Transfer error for slot 36 ep 2 on endpoint [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: ERROR Unknown event condition 198 for slot 36 ep 2 , HC probably busted [Fri Apr 10 15:44:31 2026] xhci_hcd 0000:00:14.0: Stopped on Transfer TRB for slot 36 ep 2 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam 2026-03-31 0:38 [PATCH v5 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 2026-03-31 0:38 ` [PATCH v5 1/3] USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam JP Hein 2026-03-31 0:38 ` [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware JP Hein @ 2026-03-31 0:38 ` JP Hein 2026-04-09 6:49 ` Ricardo Ribalda 2026-04-09 7:42 ` [PATCH v6 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 2026-04-10 0:28 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 4 siblings, 1 reply; 30+ messages in thread From: JP Hein @ 2026-03-31 0:38 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein, stable The Razer Kiyo Pro (1532:0e05) is a USB 3.0 webcam whose firmware has two failure modes that cascade into full xHCI host controller death, disconnecting every USB device on the bus: 1. LPM/autosuspend resume: the device fails to reinitialize its UVC endpoints on resume, producing EPIPE on SET_CUR. The stalled endpoint triggers an xHCI stop-endpoint timeout. 2. Rapid control transfers: sustained rapid SET_CUR operations (hundreds over several seconds) overwhelm the firmware. Add the device to the UVC driver table with: - UVC_QUIRK_CTRL_THROTTLE: rate-limit SET_CUR (50ms interval) and skip error-code queries after EPIPE to prevent crash trigger #2. - UVC_QUIRK_DISABLE_AUTOSUSPEND: prevent USB autosuspend transitions that trigger crash #1. Same approach as Insta360 Link. - UVC_QUIRK_NO_RESET_RESUME: avoid the fragile reset-during-resume path. Same approach as Logitech Rally Bar. Cc: stable@vger.kernel.org Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177 Signed-off-by: JP Hein <jp@jphein.com> --- drivers/media/usb/uvc/uvc_driver.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index b0ca81d92..e8b4de942 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -2920,6 +2920,23 @@ static const struct usb_device_id uvc_ids[] = { .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, + + /* + * Razer Kiyo Pro -- firmware crashes under rapid control transfers + * and on LPM/autosuspend resume, cascading into xHCI controller + * death that disconnects all USB devices on the bus. + */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x1532, + .idProduct = 0x0e05, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE + | UVC_QUIRK_DISABLE_AUTOSUSPEND + | UVC_QUIRK_NO_RESET_RESUME) }, + /* Kurokesu C1 PRO */ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO, -- 2.43.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam 2026-03-31 0:38 ` [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam JP Hein @ 2026-04-09 6:49 ` Ricardo Ribalda 2026-04-09 7:38 ` Jeffrey Hein 0 siblings, 1 reply; 30+ messages in thread From: Ricardo Ribalda @ 2026-04-09 6:49 UTC (permalink / raw) To: JP Hein Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, Michal Pecio, stable Hi JP When we add a quirk to the list we include the output of `lsusb -v -d 1532:` to the commit message. Please add it to your next version. Thanks! On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote: > > The Razer Kiyo Pro (1532:0e05) is a USB 3.0 webcam whose firmware has > two failure modes that cascade into full xHCI host controller death, > disconnecting every USB device on the bus: > > 1. LPM/autosuspend resume: the device fails to reinitialize its UVC > endpoints on resume, producing EPIPE on SET_CUR. The stalled > endpoint triggers an xHCI stop-endpoint timeout. > > 2. Rapid control transfers: sustained rapid SET_CUR operations > (hundreds over several seconds) overwhelm the firmware. > > Add the device to the UVC driver table with: > > - UVC_QUIRK_CTRL_THROTTLE: rate-limit SET_CUR (50ms interval) and > skip error-code queries after EPIPE to prevent crash trigger #2. > > - UVC_QUIRK_DISABLE_AUTOSUSPEND: prevent USB autosuspend transitions > that trigger crash #1. Same approach as Insta360 Link. > > - UVC_QUIRK_NO_RESET_RESUME: avoid the fragile reset-during-resume > path. Same approach as Logitech Rally Bar. > > Cc: stable@vger.kernel.org > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177 > Signed-off-by: JP Hein <jp@jphein.com> > --- > drivers/media/usb/uvc/uvc_driver.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c > index b0ca81d92..e8b4de942 100644 > --- a/drivers/media/usb/uvc/uvc_driver.c > +++ b/drivers/media/usb/uvc/uvc_driver.c > @@ -2920,6 +2920,23 @@ static const struct usb_device_id uvc_ids[] = { > .bInterfaceSubClass = 1, > .bInterfaceProtocol = 0, > .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, > + > + /* > + * Razer Kiyo Pro -- firmware crashes under rapid control transfers > + * and on LPM/autosuspend resume, cascading into xHCI controller > + * death that disconnects all USB devices on the bus. > + */ > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > + | USB_DEVICE_ID_MATCH_INT_INFO, > + .idVendor = 0x1532, > + .idProduct = 0x0e05, > + .bInterfaceClass = USB_CLASS_VIDEO, > + .bInterfaceSubClass = 1, > + .bInterfaceProtocol = 0, > + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE > + | UVC_QUIRK_DISABLE_AUTOSUSPEND > + | UVC_QUIRK_NO_RESET_RESUME) }, > + > /* Kurokesu C1 PRO */ > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > | USB_DEVICE_ID_MATCH_INT_INFO, > -- > 2.43.0 > -- Ricardo Ribalda ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam 2026-04-09 6:49 ` Ricardo Ribalda @ 2026-04-09 7:38 ` Jeffrey Hein 0 siblings, 0 replies; 30+ messages in thread From: Jeffrey Hein @ 2026-04-09 7:38 UTC (permalink / raw) To: Ricardo Ribalda Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, Michal Pecio, stable Hi Ricardo, On Thu, 9 Apr 2026 at 08:49, Ricardo Ribalda <ribalda@chromium.org> wrote: > When we add a quirk to the list we include the output of `lsusb -v -d > 1532:` to the commit message. Please add it to your next version. Added the Device Descriptor section from lsusb -v to the v6 commit message for patch 2/2. Thanks, JP On Wed, Apr 8, 2026 at 11:50 PM Ricardo Ribalda <ribalda@chromium.org> wrote: > > Hi JP > > When we add a quirk to the list we include the output of `lsusb -v -d > 1532:` to the commit message. Please add it to your next version. > > Thanks! > > On Tue, 31 Mar 2026 at 02:38, JP Hein <jp@jphein.com> wrote: > > > > The Razer Kiyo Pro (1532:0e05) is a USB 3.0 webcam whose firmware has > > two failure modes that cascade into full xHCI host controller death, > > disconnecting every USB device on the bus: > > > > 1. LPM/autosuspend resume: the device fails to reinitialize its UVC > > endpoints on resume, producing EPIPE on SET_CUR. The stalled > > endpoint triggers an xHCI stop-endpoint timeout. > > > > 2. Rapid control transfers: sustained rapid SET_CUR operations > > (hundreds over several seconds) overwhelm the firmware. > > > > Add the device to the UVC driver table with: > > > > - UVC_QUIRK_CTRL_THROTTLE: rate-limit SET_CUR (50ms interval) and > > skip error-code queries after EPIPE to prevent crash trigger #2. > > > > - UVC_QUIRK_DISABLE_AUTOSUSPEND: prevent USB autosuspend transitions > > that trigger crash #1. Same approach as Insta360 Link. > > > > - UVC_QUIRK_NO_RESET_RESUME: avoid the fragile reset-during-resume > > path. Same approach as Logitech Rally Bar. > > > > Cc: stable@vger.kernel.org > > Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177 > > Signed-off-by: JP Hein <jp@jphein.com> > > --- > > drivers/media/usb/uvc/uvc_driver.c | 17 +++++++++++++++++ > > 1 file changed, 17 insertions(+) > > > > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c > > index b0ca81d92..e8b4de942 100644 > > --- a/drivers/media/usb/uvc/uvc_driver.c > > +++ b/drivers/media/usb/uvc/uvc_driver.c > > @@ -2920,6 +2920,23 @@ static const struct usb_device_id uvc_ids[] = { > > .bInterfaceSubClass = 1, > > .bInterfaceProtocol = 0, > > .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, > > + > > + /* > > + * Razer Kiyo Pro -- firmware crashes under rapid control transfers > > + * and on LPM/autosuspend resume, cascading into xHCI controller > > + * death that disconnects all USB devices on the bus. > > + */ > > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > > + | USB_DEVICE_ID_MATCH_INT_INFO, > > + .idVendor = 0x1532, > > + .idProduct = 0x0e05, > > + .bInterfaceClass = USB_CLASS_VIDEO, > > + .bInterfaceSubClass = 1, > > + .bInterfaceProtocol = 0, > > + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE > > + | UVC_QUIRK_DISABLE_AUTOSUSPEND > > + | UVC_QUIRK_NO_RESET_RESUME) }, > > + > > /* Kurokesu C1 PRO */ > > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > > | USB_DEVICE_ID_MATCH_INT_INFO, > > -- > > 2.43.0 > > > > > -- > Ricardo Ribalda -- Jeffrey Pine Hein Just plain helpful. jphein.com ☀️ techempower.org (530) 798-4099 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v6 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure 2026-03-31 0:38 [PATCH v5 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein ` (2 preceding siblings ...) 2026-03-31 0:38 ` [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam JP Hein @ 2026-04-09 7:42 ` JP Hein 2026-04-09 7:42 ` [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein 2026-04-09 7:42 ` [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table JP Hein 2026-04-10 0:28 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 4 siblings, 2 replies; 30+ messages in thread From: JP Hein @ 2026-04-09 7:42 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein 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. 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. The error-code query (GET_CUR on UVC_VC_REQUEST_ERROR_CODE_CONTROL) amplifies the failure by sending a second transfer to the already-stalling device, pushing it into a full lockup and xHCI controller death. 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 v6 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() and skip the error-code query after EPIPE errors on affected devices. 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. Changes since v5: - Moved throttle from uvc_query_ctrl() to __uvc_query_ctrl() so all callers are covered, including uvc_set_video_ctrl() which bypasses the higher-level function (Ricardo Ribalda) - Throttle now applies to all query types, not just SET_CUR -- the firmware doesn't distinguish between query directions under load (Ricardo Ribalda) - Added lsusb -v Device Descriptor to patch 2/2 commit message (Ricardo Ribalda) - Bug reproduced on two separate Kiyo Pro units, confirming not unit-specific Changes since v4: - Dropped stable CC (new quirks, not regression fixes) - Updated cover letter with 6.17 test results Changes since v3: - Regenerated patches against media-committers next branch to fix context mismatch (v3 was based on Ubuntu 6.8 source) Tested on: - Kernel: 6.17.0-20-generic (Ubuntu 24.04 HWE) and 6.8.0-106-generic - Hardware: Intel Cannon Lake PCH xHCI (8086:a36d) - Device: Two Razer Kiyo Pro units (1532:0e05), firmware 1.5.0.1 Stress test, crash evidence, and debug logs: https://github.com/jphein/kiyo-xhci-fix JP Hein (2): media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware media: uvcvideo: add Razer Kiyo Pro to device info table drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++ drivers/media/usb/uvc/uvc_video.c | 30 ++++++++++++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 3 +++ 3 files changed, 49 insertions(+) -- 2.43.0 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware 2026-04-09 7:42 ` [PATCH v6 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein @ 2026-04-09 7:42 ` JP Hein 2026-04-09 7:57 ` Ricardo Ribalda 2026-04-09 7:42 ` [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table JP Hein 1 sibling, 1 reply; 30+ messages in thread From: JP Hein @ 2026-04-09 7:42 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein Some UVC devices have firmware that locks up under sustained rapid USB control transfers, crashing the xHCI host controller and taking all USB devices on the bus with it. The Razer Kiyo Pro (1532:0e05) is the first known example: approximately 25 rapid consecutive control transfers cause the firmware to stall an endpoint. The kernel's standard UVC error recovery (GET_CUR on UVC_VC_REQUEST_ERROR_CODE_CONTROL) then sends a second transfer to the already-stalling device, amplifying the failure into complete firmware lockup and xHCI controller death. Add UVC_QUIRK_CTRL_THROTTLE which: - Rate-limits all USB control transfers to 50ms intervals in __uvc_query_ctrl(), the lowest-level UVC control transfer function, ensuring all callers are throttled including uvc_set_video_ctrl() which bypasses uvc_query_ctrl() - Skips the error-code query after EPIPE to avoid amplifying stalls The 50ms interval was determined experimentally: the device is stable at this rate under sustained operation, while shorter intervals eventually trigger the firmware bug. Signed-off-by: JP Hein <jp@jphein.com> --- drivers/media/usb/uvc/uvc_video.c | 30 ++++++++++++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 3 +++ 2 files changed, 33 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index a5013a7..cee93ac 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -36,6 +36,26 @@ static int __uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, u8 type = USB_TYPE_CLASS | USB_RECIP_INTERFACE; unsigned int pipe; + /* + * Rate-limit control transfers for devices with fragile firmware. + * The Razer Kiyo Pro locks up under sustained rapid control + * transfers (hundreds without delay), crashing the xHCI controller. + * Throttle in this low-level function to cover all callers, + * including uvc_set_video_ctrl() which bypasses uvc_query_ctrl(). + */ + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) { + unsigned long min_interval = msecs_to_jiffies(50); + + if (dev->last_ctrl_jiffies && + time_before(jiffies, + dev->last_ctrl_jiffies + min_interval)) { + unsigned long wait = dev->last_ctrl_jiffies + + min_interval - jiffies; + msleep(jiffies_to_msecs(wait)); + } + dev->last_ctrl_jiffies = jiffies; + } + pipe = (query & 0x80) ? usb_rcvctrlpipe(dev->udev, 0) : usb_sndctrlpipe(dev->udev, 0); type |= (query & 0x80) ? USB_DIR_IN : USB_DIR_OUT; @@ -108,6 +128,16 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, return ret < 0 ? ret : -EPIPE; } + /* + * Skip the error code query for devices that crash under load. + * The standard error-code query (GET_CUR on + * UVC_VC_REQUEST_ERROR_CODE_CONTROL) sends a second USB transfer to + * a device that is already stalling, which can amplify the failure + * into a full firmware lockup and xHCI controller death. + */ + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) + return -EPIPE; + /* Reuse data[0] to request the error code. */ tmp = *(u8 *)data; diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index 757254f..31f2af5 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -78,6 +78,7 @@ #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000 #define UVC_QUIRK_MJPEG_NO_EOF 0x00020000 #define UVC_QUIRK_MSXU_META 0x00040000 +#define UVC_QUIRK_CTRL_THROTTLE 0x00080000 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x00000001 @@ -583,6 +584,8 @@ struct uvc_device { struct usb_interface *intf; unsigned long warnings; u32 quirks; + /* UVC control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */ + unsigned long last_ctrl_jiffies; int intfnum; char name[32]; -- 2.43.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware 2026-04-09 7:42 ` [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein @ 2026-04-09 7:57 ` Ricardo Ribalda 2026-04-09 8:12 ` Jeffrey Hein 0 siblings, 1 reply; 30+ messages in thread From: Ricardo Ribalda @ 2026-04-09 7:57 UTC (permalink / raw) To: JP Hein Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, Michal Pecio On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote: > > Some UVC devices have firmware that locks up under sustained rapid > USB control transfers, crashing the xHCI host controller and taking > all USB devices on the bus with it. > > The Razer Kiyo Pro (1532:0e05) is the first known example: approximately > 25 rapid consecutive control transfers cause the firmware to stall an > endpoint. The kernel's standard UVC error recovery (GET_CUR on > UVC_VC_REQUEST_ERROR_CODE_CONTROL) then sends a second transfer to the > already-stalling device, amplifying the failure into complete firmware > lockup and xHCI controller death. > > Add UVC_QUIRK_CTRL_THROTTLE which: > - Rate-limits all USB control transfers to 50ms intervals in > __uvc_query_ctrl(), the lowest-level UVC control transfer function, > ensuring all callers are throttled including uvc_set_video_ctrl() > which bypasses uvc_query_ctrl() > - Skips the error-code query after EPIPE to avoid amplifying stalls > > The 50ms interval was determined experimentally: the device is stable > at this rate under sustained operation, while shorter intervals > eventually trigger the firmware bug. > > Signed-off-by: JP Hein <jp@jphein.com> > --- > drivers/media/usb/uvc/uvc_video.c | 30 ++++++++++++++++++++++++++++++ > drivers/media/usb/uvc/uvcvideo.h | 3 +++ > 2 files changed, 33 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index a5013a7..cee93ac 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -36,6 +36,26 @@ static int __uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, > u8 type = USB_TYPE_CLASS | USB_RECIP_INTERFACE; > unsigned int pipe; > > + /* > + * Rate-limit control transfers for devices with fragile firmware. > + * The Razer Kiyo Pro locks up under sustained rapid control > + * transfers (hundreds without delay), crashing the xHCI controller. > + * Throttle in this low-level function to cover all callers, > + * including uvc_set_video_ctrl() which bypasses uvc_query_ctrl(). > + */ > + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) { > + unsigned long min_interval = msecs_to_jiffies(50); > + > + if (dev->last_ctrl_jiffies && > + time_before(jiffies, > + dev->last_ctrl_jiffies + min_interval)) { > + unsigned long wait = dev->last_ctrl_jiffies + > + min_interval - jiffies; > + msleep(jiffies_to_msecs(wait)); > + } > + dev->last_ctrl_jiffies = jiffies; > + } > + > pipe = (query & 0x80) ? usb_rcvctrlpipe(dev->udev, 0) > : usb_sndctrlpipe(dev->udev, 0); > type |= (query & 0x80) ? USB_DIR_IN : USB_DIR_OUT; > @@ -108,6 +128,16 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, > return ret < 0 ? ret : -EPIPE; > } > > + /* > + * Skip the error code query for devices that crash under load. > + * The standard error-code query (GET_CUR on > + * UVC_VC_REQUEST_ERROR_CODE_CONTROL) sends a second USB transfer to > + * a device that is already stalling, which can amplify the failure > + * into a full firmware lockup and xHCI controller death. > + */ > + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) > + return -EPIPE; I do not believe this is needed anymore now that the check is in the inner funcion > + > /* Reuse data[0] to request the error code. */ > tmp = *(u8 *)data; > > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h > index 757254f..31f2af5 100644 > --- a/drivers/media/usb/uvc/uvcvideo.h > +++ b/drivers/media/usb/uvc/uvcvideo.h > @@ -78,6 +78,7 @@ > #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000 > #define UVC_QUIRK_MJPEG_NO_EOF 0x00020000 > #define UVC_QUIRK_MSXU_META 0x00040000 > +#define UVC_QUIRK_CTRL_THROTTLE 0x00080000 > > /* Format flags */ > #define UVC_FMT_FLAG_COMPRESSED 0x00000001 > @@ -583,6 +584,8 @@ struct uvc_device { > struct usb_interface *intf; > unsigned long warnings; > u32 quirks; > + /* UVC control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */ > + unsigned long last_ctrl_jiffies; > int intfnum; > char name[32]; > > -- > 2.43.0 > -- Ricardo Ribalda ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware 2026-04-09 7:57 ` Ricardo Ribalda @ 2026-04-09 8:12 ` Jeffrey Hein 0 siblings, 0 replies; 30+ messages in thread From: Jeffrey Hein @ 2026-04-09 8:12 UTC (permalink / raw) To: Ricardo Ribalda Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, Michal Pecio Hi Ricardo, Agreed -- the error-code query goes through __uvc_query_ctrl() now, so it gets the 50ms throttle automatically. Dropped in v7. Thanks, JP On Thu, Apr 9, 2026 at 12:57 AM Ricardo Ribalda <ribalda@chromium.org> wrote: > > On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote: > > > > Some UVC devices have firmware that locks up under sustained rapid > > USB control transfers, crashing the xHCI host controller and taking > > all USB devices on the bus with it. > > > > The Razer Kiyo Pro (1532:0e05) is the first known example: approximately > > 25 rapid consecutive control transfers cause the firmware to stall an > > endpoint. The kernel's standard UVC error recovery (GET_CUR on > > UVC_VC_REQUEST_ERROR_CODE_CONTROL) then sends a second transfer to the > > already-stalling device, amplifying the failure into complete firmware > > lockup and xHCI controller death. > > > > Add UVC_QUIRK_CTRL_THROTTLE which: > > - Rate-limits all USB control transfers to 50ms intervals in > > __uvc_query_ctrl(), the lowest-level UVC control transfer function, > > ensuring all callers are throttled including uvc_set_video_ctrl() > > which bypasses uvc_query_ctrl() > > - Skips the error-code query after EPIPE to avoid amplifying stalls > > > > The 50ms interval was determined experimentally: the device is stable > > at this rate under sustained operation, while shorter intervals > > eventually trigger the firmware bug. > > > > Signed-off-by: JP Hein <jp@jphein.com> > > --- > > drivers/media/usb/uvc/uvc_video.c | 30 ++++++++++++++++++++++++++++++ > > drivers/media/usb/uvc/uvcvideo.h | 3 +++ > > 2 files changed, 33 insertions(+) > > > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > > index a5013a7..cee93ac 100644 > > --- a/drivers/media/usb/uvc/uvc_video.c > > +++ b/drivers/media/usb/uvc/uvc_video.c > > @@ -36,6 +36,26 @@ static int __uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, > > u8 type = USB_TYPE_CLASS | USB_RECIP_INTERFACE; > > unsigned int pipe; > > > > + /* > > + * Rate-limit control transfers for devices with fragile firmware. > > + * The Razer Kiyo Pro locks up under sustained rapid control > > + * transfers (hundreds without delay), crashing the xHCI controller. > > + * Throttle in this low-level function to cover all callers, > > + * including uvc_set_video_ctrl() which bypasses uvc_query_ctrl(). > > + */ > > + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) { > > + unsigned long min_interval = msecs_to_jiffies(50); > > + > > + if (dev->last_ctrl_jiffies && > > + time_before(jiffies, > > + dev->last_ctrl_jiffies + min_interval)) { > > + unsigned long wait = dev->last_ctrl_jiffies + > > + min_interval - jiffies; > > + msleep(jiffies_to_msecs(wait)); > > + } > > + dev->last_ctrl_jiffies = jiffies; > > + } > > + > > pipe = (query & 0x80) ? usb_rcvctrlpipe(dev->udev, 0) > > : usb_sndctrlpipe(dev->udev, 0); > > type |= (query & 0x80) ? USB_DIR_IN : USB_DIR_OUT; > > @@ -108,6 +128,16 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, > > return ret < 0 ? ret : -EPIPE; > > } > > > > + /* > > + * Skip the error code query for devices that crash under load. > > + * The standard error-code query (GET_CUR on > > + * UVC_VC_REQUEST_ERROR_CODE_CONTROL) sends a second USB transfer to > > + * a device that is already stalling, which can amplify the failure > > + * into a full firmware lockup and xHCI controller death. > > + */ > > + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) > > + return -EPIPE; > > I do not believe this is needed anymore now that the check is in the > inner funcion > > > + > > /* Reuse data[0] to request the error code. */ > > tmp = *(u8 *)data; > > > > diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h > > index 757254f..31f2af5 100644 > > --- a/drivers/media/usb/uvc/uvcvideo.h > > +++ b/drivers/media/usb/uvc/uvcvideo.h > > @@ -78,6 +78,7 @@ > > #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000 > > #define UVC_QUIRK_MJPEG_NO_EOF 0x00020000 > > #define UVC_QUIRK_MSXU_META 0x00040000 > > +#define UVC_QUIRK_CTRL_THROTTLE 0x00080000 > > > > /* Format flags */ > > #define UVC_FMT_FLAG_COMPRESSED 0x00000001 > > @@ -583,6 +584,8 @@ struct uvc_device { > > struct usb_interface *intf; > > unsigned long warnings; > > u32 quirks; > > + /* UVC control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */ > > + unsigned long last_ctrl_jiffies; > > int intfnum; > > char name[32]; > > > > -- > > 2.43.0 > > > > > -- > Ricardo Ribalda ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table 2026-04-09 7:42 ` [PATCH v6 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 2026-04-09 7:42 ` [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein @ 2026-04-09 7:42 ` JP Hein 2026-04-09 7:57 ` Ricardo Ribalda 1 sibling, 1 reply; 30+ messages in thread From: JP Hein @ 2026-04-09 7:42 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein Add a device entry for the Razer Kiyo Pro (1532:0e05) with quirks to work around firmware bugs that crash the xHCI host controller: UVC_QUIRK_CTRL_THROTTLE - rate-limit control transfers and skip error-code queries after EPIPE UVC_QUIRK_DISABLE_AUTOSUSPEND - prevent runtime suspend UVC_QUIRK_NO_RESET_RESUME - skip post-reset reinitialization The firmware (v1.5.0.1) has two failure modes: it stalls endpoints under rapid control transfers (~25 without delay), and it fails to reinitialize properly after USB power state transitions. Both can cascade into xHCI controller death, disconnecting all USB devices on the bus. Bug reproduced on two separate Kiyo Pro units running simultaneously, confirming the issue is not unit-specific. lsusb -v: Bus 002 Device 002: ID 1532:0e05 Razer USA, Ltd Razer Kiyo Pro Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 [unknown] bDeviceProtocol 1 Interface Association bMaxPacketSize0 9 idVendor 0x1532 Razer USA, Ltd idProduct 0x0e05 Razer Kiyo Pro bcdDevice 8.21 iManufacturer 1 Razer Inc iProduct 2 Razer Kiyo Pro iSerial 0 Signed-off-by: JP Hein <jp@jphein.com> --- drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 775bede..9b6df8e 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -2880,6 +2880,22 @@ static const struct usb_device_id uvc_ids[] = { .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, + + /* + * Razer Kiyo Pro -- firmware crashes under rapid control transfers + * and on LPM/autosuspend resume, cascading into xHCI controller + * death that disconnects all USB devices on the bus. + */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x1532, + .idProduct = 0x0e05, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE + | UVC_QUIRK_DISABLE_AUTOSUSPEND + | UVC_QUIRK_NO_RESET_RESUME) }, /* Kurokesu C1 PRO */ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO, -- 2.43.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table 2026-04-09 7:42 ` [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table JP Hein @ 2026-04-09 7:57 ` Ricardo Ribalda 2026-04-09 8:13 ` Jeffrey Hein 0 siblings, 1 reply; 30+ messages in thread From: Ricardo Ribalda @ 2026-04-09 7:57 UTC (permalink / raw) To: JP Hein Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, Michal Pecio Hi On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote: > > Add a device entry for the Razer Kiyo Pro (1532:0e05) with quirks to > work around firmware bugs that crash the xHCI host controller: > > UVC_QUIRK_CTRL_THROTTLE - rate-limit control transfers and skip > error-code queries after EPIPE > UVC_QUIRK_DISABLE_AUTOSUSPEND - prevent runtime suspend > UVC_QUIRK_NO_RESET_RESUME - skip post-reset reinitialization > > The firmware (v1.5.0.1) has two failure modes: it stalls endpoints > under rapid control transfers (~25 without delay), and it fails to > reinitialize properly after USB power state transitions. Both can > cascade into xHCI controller death, disconnecting all USB devices on > the bus. > > Bug reproduced on two separate Kiyo Pro units running simultaneously, > confirming the issue is not unit-specific. > > lsusb -v: > Bus 002 Device 002: ID 1532:0e05 Razer USA, Ltd Razer Kiyo Pro > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 3.20 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 [unknown] > bDeviceProtocol 1 Interface Association > bMaxPacketSize0 9 > idVendor 0x1532 Razer USA, Ltd > idProduct 0x0e05 Razer Kiyo Pro > bcdDevice 8.21 > iManufacturer 1 Razer Inc > iProduct 2 Razer Kiyo Pro > iSerial 0 > Is this the whole output of lsusb?? Can you try with lsusb -vv? > Signed-off-by: JP Hein <jp@jphein.com> > --- > drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c > index 775bede..9b6df8e 100644 > --- a/drivers/media/usb/uvc/uvc_driver.c > +++ b/drivers/media/usb/uvc/uvc_driver.c > @@ -2880,6 +2880,22 @@ static const struct usb_device_id uvc_ids[] = { > .bInterfaceSubClass = 1, > .bInterfaceProtocol = 0, > .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, > + > + /* > + * Razer Kiyo Pro -- firmware crashes under rapid control transfers > + * and on LPM/autosuspend resume, cascading into xHCI controller > + * death that disconnects all USB devices on the bus. > + */ > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > + | USB_DEVICE_ID_MATCH_INT_INFO, > + .idVendor = 0x1532, > + .idProduct = 0x0e05, > + .bInterfaceClass = USB_CLASS_VIDEO, > + .bInterfaceSubClass = 1, > + .bInterfaceProtocol = 0, > + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE > + | UVC_QUIRK_DISABLE_AUTOSUSPEND > + | UVC_QUIRK_NO_RESET_RESUME) }, > /* Kurokesu C1 PRO */ > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > | USB_DEVICE_ID_MATCH_INT_INFO, > -- > 2.43.0 > -- Ricardo Ribalda ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table 2026-04-09 7:57 ` Ricardo Ribalda @ 2026-04-09 8:13 ` Jeffrey Hein 0 siblings, 0 replies; 30+ messages in thread From: Jeffrey Hein @ 2026-04-09 8:13 UTC (permalink / raw) To: Ricardo Ribalda Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, Michal Pecio Hi Ricardo, Full lsusb -vv output included in the v7 commit message. Thanks, JP On Thu, Apr 9, 2026 at 12:58 AM Ricardo Ribalda <ribalda@chromium.org> wrote: > > Hi > > On Thu, 9 Apr 2026 at 09:44, JP Hein <jp@jphein.com> wrote: > > > > Add a device entry for the Razer Kiyo Pro (1532:0e05) with quirks to > > work around firmware bugs that crash the xHCI host controller: > > > > UVC_QUIRK_CTRL_THROTTLE - rate-limit control transfers and skip > > error-code queries after EPIPE > > UVC_QUIRK_DISABLE_AUTOSUSPEND - prevent runtime suspend > > UVC_QUIRK_NO_RESET_RESUME - skip post-reset reinitialization > > > > The firmware (v1.5.0.1) has two failure modes: it stalls endpoints > > under rapid control transfers (~25 without delay), and it fails to > > reinitialize properly after USB power state transitions. Both can > > cascade into xHCI controller death, disconnecting all USB devices on > > the bus. > > > > Bug reproduced on two separate Kiyo Pro units running simultaneously, > > confirming the issue is not unit-specific. > > > > lsusb -v: > > Bus 002 Device 002: ID 1532:0e05 Razer USA, Ltd Razer Kiyo Pro > > Device Descriptor: > > bLength 18 > > bDescriptorType 1 > > bcdUSB 3.20 > > bDeviceClass 239 Miscellaneous Device > > bDeviceSubClass 2 [unknown] > > bDeviceProtocol 1 Interface Association > > bMaxPacketSize0 9 > > idVendor 0x1532 Razer USA, Ltd > > idProduct 0x0e05 Razer Kiyo Pro > > bcdDevice 8.21 > > iManufacturer 1 Razer Inc > > iProduct 2 Razer Kiyo Pro > > iSerial 0 > > > > Is this the whole output of lsusb?? Can you try with lsusb -vv? > > > Signed-off-by: JP Hein <jp@jphein.com> > > --- > > drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c > > index 775bede..9b6df8e 100644 > > --- a/drivers/media/usb/uvc/uvc_driver.c > > +++ b/drivers/media/usb/uvc/uvc_driver.c > > @@ -2880,6 +2880,22 @@ static const struct usb_device_id uvc_ids[] = { > > .bInterfaceSubClass = 1, > > .bInterfaceProtocol = 0, > > .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, > > + > > + /* > > + * Razer Kiyo Pro -- firmware crashes under rapid control transfers > > + * and on LPM/autosuspend resume, cascading into xHCI controller > > + * death that disconnects all USB devices on the bus. > > + */ > > + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > > + | USB_DEVICE_ID_MATCH_INT_INFO, > > + .idVendor = 0x1532, > > + .idProduct = 0x0e05, > > + .bInterfaceClass = USB_CLASS_VIDEO, > > + .bInterfaceSubClass = 1, > > + .bInterfaceProtocol = 0, > > + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE > > + | UVC_QUIRK_DISABLE_AUTOSUSPEND > > + | UVC_QUIRK_NO_RESET_RESUME) }, > > /* Kurokesu C1 PRO */ > > { .match_flags = USB_DEVICE_ID_MATCH_DEVICE > > | USB_DEVICE_ID_MATCH_INT_INFO, > > -- > > 2.43.0 > > > > > -- > Ricardo Ribalda ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure 2026-03-31 0:38 [PATCH v5 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein ` (3 preceding siblings ...) 2026-04-09 7:42 ` [PATCH v6 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein @ 2026-04-10 0:28 ` JP Hein 2026-04-10 0:28 ` [PATCH v7 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein ` (2 more replies) 4 siblings, 3 replies; 30+ messages in thread From: JP Hein @ 2026-04-10 0:28 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein 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. 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. 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. Changes since v6: - Dropped the error-code query skip after EPIPE -- no longer needed since the throttle in __uvc_query_ctrl() already rate-limits the error-code query path (Ricardo Ribalda) - Included full lsusb -vv output in patch 2/2 commit message (Ricardo Ribalda) Changes since v5: - Moved throttle from uvc_query_ctrl() to __uvc_query_ctrl() so all callers are covered, including uvc_set_video_ctrl() which bypasses the higher-level function (Ricardo Ribalda) - Throttle now applies to all query types, not just SET_CUR (Ricardo Ribalda) Changes since v4: - Dropped stable CC (new quirks, not regression fixes) - Updated cover letter with 6.17 test results Changes since v3: - Regenerated patches against media-committers next branch to fix context mismatch (v3 was based on Ubuntu 6.8 source) Tested on: - Kernel: 6.17.0-20-generic (Ubuntu 24.04 HWE) and 6.8.0-106-generic - Hardware: Intel Cannon Lake PCH xHCI (8086:a36d) - Device: Two Razer Kiyo Pro units (1532:0e05), firmware 1.5.0.1 Stress test, crash evidence, and debug logs: https://github.com/jphein/kiyo-xhci-fix JP Hein (2): media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware media: uvcvideo: add Razer Kiyo Pro to device info table drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++ drivers/media/usb/uvc/uvc_video.c | 20 ++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 3 +++ 3 files changed, 39 insertions(+) -- 2.43.0 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v7 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware 2026-04-10 0:28 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein @ 2026-04-10 0:28 ` JP Hein 2026-04-10 0:28 ` [PATCH v7 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table JP Hein 2026-04-13 20:40 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure Michal Pecio 2 siblings, 0 replies; 30+ messages in thread From: JP Hein @ 2026-04-10 0:28 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein Some UVC devices have firmware that locks up under sustained rapid USB control transfers, crashing the xHCI host controller and taking all USB devices on the bus with it. The Razer Kiyo Pro (1532:0e05) is the first known example: approximately 25 rapid consecutive control transfers cause the firmware to stall an endpoint. Add UVC_QUIRK_CTRL_THROTTLE which rate-limits all USB control transfers to 50ms intervals in __uvc_query_ctrl(), the lowest-level UVC control transfer function, ensuring all callers are throttled including uvc_set_video_ctrl() which bypasses uvc_query_ctrl(). The 50ms interval was determined experimentally: the device is stable at this rate under sustained operation, while shorter intervals eventually trigger the firmware bug. Signed-off-by: JP Hein <jp@jphein.com> --- drivers/media/usb/uvc/uvc_video.c | 20 ++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 3 +++ 2 files changed, 23 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c index a5013a7..1d1206f 100644 --- a/drivers/media/usb/uvc/uvc_video.c +++ b/drivers/media/usb/uvc/uvc_video.c @@ -36,6 +36,26 @@ static int __uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 unit, u8 type = USB_TYPE_CLASS | USB_RECIP_INTERFACE; unsigned int pipe; + /* + * Rate-limit control transfers for devices with fragile firmware. + * The Razer Kiyo Pro locks up under sustained rapid control + * transfers (hundreds without delay), crashing the xHCI controller. + * Throttle in this low-level function to cover all callers, + * including uvc_set_video_ctrl() which bypasses uvc_query_ctrl(). + */ + if (dev->quirks & UVC_QUIRK_CTRL_THROTTLE) { + unsigned long min_interval = msecs_to_jiffies(50); + + if (dev->last_ctrl_jiffies && + time_before(jiffies, + dev->last_ctrl_jiffies + min_interval)) { + unsigned long wait = dev->last_ctrl_jiffies + + min_interval - jiffies; + msleep(jiffies_to_msecs(wait)); + } + dev->last_ctrl_jiffies = jiffies; + } + pipe = (query & 0x80) ? usb_rcvctrlpipe(dev->udev, 0) : usb_sndctrlpipe(dev->udev, 0); type |= (query & 0x80) ? USB_DIR_IN : USB_DIR_OUT; diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index 757254f..31f2af5 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -78,6 +78,7 @@ #define UVC_QUIRK_INVALID_DEVICE_SOF 0x00010000 #define UVC_QUIRK_MJPEG_NO_EOF 0x00020000 #define UVC_QUIRK_MSXU_META 0x00040000 +#define UVC_QUIRK_CTRL_THROTTLE 0x00080000 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x00000001 @@ -583,6 +584,8 @@ struct uvc_device { struct usb_interface *intf; unsigned long warnings; u32 quirks; + /* UVC control transfer throttling (UVC_QUIRK_CTRL_THROTTLE) */ + unsigned long last_ctrl_jiffies; int intfnum; char name[32]; -- 2.43.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v7 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table 2026-04-10 0:28 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 2026-04-10 0:28 ` [PATCH v7 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein @ 2026-04-10 0:28 ` JP Hein 2026-04-13 20:40 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure Michal Pecio 2 siblings, 0 replies; 30+ messages in thread From: JP Hein @ 2026-04-10 0:28 UTC (permalink / raw) To: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman Cc: linux-media, linux-usb, Ricardo Ribalda, Michal Pecio, JP Hein Add a device entry for the Razer Kiyo Pro (1532:0e05) with quirks to work around firmware bugs that crash the xHCI host controller: UVC_QUIRK_CTRL_THROTTLE - rate-limit control transfers to prevent firmware lockup under sustained load UVC_QUIRK_DISABLE_AUTOSUSPEND - prevent runtime suspend UVC_QUIRK_NO_RESET_RESUME - skip post-reset reinitialization The firmware (v1.5.0.1) has two failure modes: it stalls endpoints under rapid control transfers (~25 without delay), and it fails to reinitialize properly after USB power state transitions. Both can cascade into xHCI controller death, disconnecting all USB devices on the bus. Bug reproduced on two separate Kiyo Pro units running simultaneously, confirming the issue is not unit-specific. lsusb -vv: Bus 002 Device 002: ID 1532:0e05 Razer USA, Ltd Razer Kiyo Pro Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 [unknown] bDeviceProtocol 1 Interface Association bMaxPacketSize0 9 idVendor 0x1532 Razer USA, Ltd idProduct 0x0e05 Razer Kiyo Pro bcdDevice 8.21 iManufacturer 1 Razer Inc iProduct 2 Razer Kiyo Pro iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x05b4 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 896mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 0 VideoControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 0x0069 dwClockFrequency 30.000000MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 2 iTerminal 0 VideoControl Interface Descriptor: bLength 27 bDescriptorType 36 bDescriptorSubtype 6 (EXTENSION_UNIT) bUnitID 2 guidExtensionCode {2c49d16a-32b8-4485-3ea8-643a152362f2} bNumControls 6 bNrInPins 1 baSourceID( 0) 6 bControlSize 2 bmControls( 0) 0x3f bmControls( 1) 0x00 iExtension 0 VideoControl Interface Descriptor: bLength 27 bDescriptorType 36 bDescriptorSubtype 6 (EXTENSION_UNIT) bUnitID 6 guidExtensionCode {23e49ed0-1178-4f31-ae52-d2fb8a8d3b48} bNumControls 5 bNrInPins 1 baSourceID( 0) 3 bControlSize 2 bmControls( 0) 0xff bmControls( 1) 0x7f iExtension 0 VideoControl Interface Descriptor: bLength 18 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax 0 wOcularFocalLength 0 bControlSize 3 bmControls 0x00020a2e Auto-Exposure Mode Auto-Exposure Priority Exposure Time (Absolute) Focus (Absolute) Zoom (Absolute) PanTilt (Absolute) Focus, Auto VideoControl Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 5 (PROCESSING_UNIT) Warning: Descriptor too short bUnitID 3 bSourceID 1 wMaxMultiplier 0 bControlSize 2 bmControls 0x0000175b Brightness Contrast Saturation Sharpness White Balance Temperature Backlight Compensation Gain Power Line Frequency White Balance Temperature, Auto iProcessing 0 bmVideoStandards 0xff None NTSC - 525/60 PAL - 625/50 SECAM - 625/50 NTSC - 625/50 PAL - 525/60 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 8 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 14 Video bInterfaceSubClass 2 Video Streaming bInterfaceProtocol 0 iInterface 0 VideoStreaming Interface Descriptor: bLength 17 bDescriptorType 36 bDescriptorSubtype 1 (INPUT_HEADER) bNumFormats 4 wTotalLength 0x03e6 bEndpointAddress 0x81 EP 1 IN bmInfo 0 bTerminalLink 4 bStillCaptureMethod 0 bTriggerSupport 0 bTriggerUsage 0 bControlSize 1 bmaControls( 0) 0 bmaControls( 1) 0 bmaControls( 2) 0 bmaControls( 3) 0 VideoStreaming Interface Descriptor: bLength 27 bDescriptorType 36 bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED) bFormatIndex 1 bNumFrameDescriptors 4 guidFormat {32595559-0000-0010-8000-00aa00389b71} bBitsPerPixel 16 bDefaultFrameIndex 1 bAspectRatioX 0 bAspectRatioY 0 bmInterlaceFlags 0x00 Interlaced stream or variable: No Fields per frame: 2 fields Field 1 first: No Field pattern: Field 1 only bCopyProtect 0 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 1 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 480 dwMinBitRate 294912000 dwMaxBitRate 294912000 dwMaxVideoFrameBufferSize 614400 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 7 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 360 dwMinBitRate 221184000 dwMaxBitRate 221184000 dwMaxVideoFrameBufferSize 460800 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 11 bmCapabilities 0x00 Still image unsupported wWidth 1280 wHeight 720 dwMinBitRate 884736000 dwMaxBitRate 884736000 dwMaxVideoFrameBufferSize 1843200 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 13 bmCapabilities 0x00 Still image unsupported wWidth 1920 wHeight 1080 dwMinBitRate 1990656000 dwMaxBitRate 1990656000 dwMaxVideoFrameBufferSize 4147200 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 13 (COLORFORMAT) bColorPrimaries 1 (BT.709,sRGB) bTransferCharacteristics 1 (BT.709) bMatrixCoefficients 4 (SMPTE 170M (BT.601)) VideoStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 6 (FORMAT_MJPEG) bFormatIndex 2 bNumFrameDescriptors 4 bFlags 0 Fixed-size samples: No bDefaultFrameIndex 1 bAspectRatioX 0 bAspectRatioY 0 bmInterlaceFlags 0x00 Interlaced stream or variable: No Fields per frame: 1 fields Field 1 first: No Field pattern: Field 1 only bCopyProtect 0 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 7 (FRAME_MJPEG) bFrameIndex 1 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 480 dwMinBitRate 294912000 dwMaxBitRate 294912000 dwMaxVideoFrameBufferSize 614400 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 7 (FRAME_MJPEG) bFrameIndex 7 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 360 dwMinBitRate 221184000 dwMaxBitRate 221184000 dwMaxVideoFrameBufferSize 460800 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 7 (FRAME_MJPEG) bFrameIndex 11 bmCapabilities 0x00 Still image unsupported wWidth 1280 wHeight 720 dwMinBitRate 884736000 dwMaxBitRate 884736000 dwMaxVideoFrameBufferSize 1843200 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 7 (FRAME_MJPEG) bFrameIndex 13 bmCapabilities 0x00 Still image unsupported wWidth 1920 wHeight 1080 dwMinBitRate 1990656000 dwMaxBitRate 1990656000 dwMaxVideoFrameBufferSize 4147200 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 13 (COLORFORMAT) bColorPrimaries 1 (BT.709,sRGB) bTransferCharacteristics 1 (BT.709) bMatrixCoefficients 4 (SMPTE 170M (BT.601)) VideoStreaming Interface Descriptor: bLength 28 bDescriptorType 36 bDescriptorSubtype 16 (FORMAT_FRAME_BASED) bFormatIndex 3 bNumFrameDescriptors 4 guidFormat {34363248-0000-0010-8000-00aa00389b71} bBitsPerPixel 16 bDefaultFrameIndex 1 bAspectRatioX 0 bAspectRatioY 0 bmInterlaceFlags 0x00 Interlaced stream or variable: No Fields per frame: 2 fields Field 1 first: No Field pattern: Field 1 only bCopyProtect 0 bVariableSize 1 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 17 (FRAME_FRAME_BASED) bFrameIndex 1 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 480 dwMinBitRate 251658240 dwMaxBitRate 503316480 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwBytesPerLine 0 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 17 (FRAME_FRAME_BASED) bFrameIndex 9 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 360 dwMinBitRate 251658240 dwMaxBitRate 503316480 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwBytesPerLine 0 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 17 (FRAME_FRAME_BASED) bFrameIndex 15 bmCapabilities 0x00 Still image unsupported wWidth 1280 wHeight 720 dwMinBitRate 251658240 dwMaxBitRate 503316480 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwBytesPerLine 0 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 17 (FRAME_FRAME_BASED) bFrameIndex 17 bmCapabilities 0x00 Still image unsupported wWidth 1920 wHeight 1080 dwMinBitRate 251658240 dwMaxBitRate 503316480 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwBytesPerLine 0 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 13 (COLORFORMAT) bColorPrimaries 1 (BT.709,sRGB) bTransferCharacteristics 1 (BT.709) bMatrixCoefficients 4 (SMPTE 170M (BT.601)) VideoStreaming Interface Descriptor: bLength 27 bDescriptorType 36 bDescriptorSubtype 4 (FORMAT_UNCOMPRESSED) bFormatIndex 4 bNumFrameDescriptors 4 guidFormat {3231564e-0000-0010-8000-00aa00389b71} bBitsPerPixel 12 bDefaultFrameIndex 1 bAspectRatioX 0 bAspectRatioY 0 bmInterlaceFlags 0x00 Interlaced stream or variable: No Fields per frame: 2 fields Field 1 first: No Field pattern: Field 1 only bCopyProtect 0 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 1 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 480 dwMinBitRate 221184000 dwMaxBitRate 221184000 dwMaxVideoFrameBufferSize 460800 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 2 bmCapabilities 0x00 Still image unsupported wWidth 640 wHeight 360 dwMinBitRate 165888000 dwMaxBitRate 165888000 dwMaxVideoFrameBufferSize 345600 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 3 bmCapabilities 0x00 Still image unsupported wWidth 1280 wHeight 720 dwMinBitRate 663552000 dwMaxBitRate 663552000 dwMaxVideoFrameBufferSize 1382400 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 54 bDescriptorType 36 bDescriptorSubtype 5 (FRAME_UNCOMPRESSED) bFrameIndex 4 bmCapabilities 0x00 Still image unsupported wWidth 1920 wHeight 1080 dwMinBitRate 1492992000 dwMaxBitRate 1492992000 dwMaxVideoFrameBufferSize 3110400 dwDefaultFrameInterval 166666 bFrameIntervalType 7 dwFrameInterval( 0) 166666 dwFrameInterval( 1) 333333 dwFrameInterval( 2) 416666 dwFrameInterval( 3) 500000 dwFrameInterval( 4) 666666 dwFrameInterval( 5) 1000000 dwFrameInterval( 6) 2000000 VideoStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 13 (COLORFORMAT) bColorPrimaries 1 (BT.709,sRGB) bTransferCharacteristics 1 (BT.709) bMatrixCoefficients 4 (SMPTE 170M (BT.601)) Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 14 Video bInterfaceSubClass 2 Video Streaming bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 1 bMaxBurst 0 Mult 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 14 Video bInterfaceSubClass 2 Video Streaming bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 1 bMaxBurst 10 Mult 2 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 2 bInterfaceCount 2 bFunctionClass 1 Audio bFunctionSubClass 2 Streaming bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 0x0026 bInCollection 1 baInterfaceNr(0) 3 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 5 iTerminal 0 AudioControl Interface Descriptor: bLength 8 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 5 bSourceID 1 bControlSize 1 bmaControls(0) 0x03 Mute Control Volume Control iFeature 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 3 bDelay 2 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x00c4 1x 196 bytes bInterval 4 bRefresh 0 bSynchAddress 0 bMaxBurst 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 3 bDelay 2 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 16000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0044 1x 68 bytes bInterval 4 bRefresh 0 bSynchAddress 0 bMaxBurst 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 3 bDelay 2 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 24000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0064 1x 100 bytes bInterval 4 bRefresh 0 bSynchAddress 0 bMaxBurst 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 4 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 3 bDelay 2 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 32000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0084 1x 132 bytes bInterval 4 bRefresh 0 bSynchAddress 0 bMaxBurst 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 0 Undefined wLockDelay 0x0000 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000006 BESL Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 2 Lowest fully-functional device speed is High Speed (480Mbps) bU1DevExitLat 10 micro seconds bU2DevExitLat 256 micro seconds Device Status: 0x0000 (Bus Powered) Signed-off-by: JP Hein <jp@jphein.com> --- drivers/media/usb/uvc/uvc_driver.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 775bede..9b6df8e 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -2880,6 +2880,22 @@ static const struct usb_device_id uvc_ids[] = { .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, + + /* + * Razer Kiyo Pro -- firmware crashes under rapid control transfers + * and on LPM/autosuspend resume, cascading into xHCI controller + * death that disconnects all USB devices on the bus. + */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x1532, + .idProduct = 0x0e05, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_CTRL_THROTTLE + | UVC_QUIRK_DISABLE_AUTOSUSPEND + | UVC_QUIRK_NO_RESET_RESUME) }, /* Kurokesu C1 PRO */ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO, -- 2.43.0 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure 2026-04-10 0:28 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein 2026-04-10 0:28 ` [PATCH v7 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein 2026-04-10 0:28 ` [PATCH v7 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table JP Hein @ 2026-04-13 20:40 ` Michal Pecio 2 siblings, 0 replies; 30+ messages in thread From: Michal Pecio @ 2026-04-13 20:40 UTC (permalink / raw) To: JP Hein Cc: Laurent Pinchart, Hans de Goede, Greg Kroah-Hartman, linux-media, linux-usb, Ricardo Ribalda 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2026-04-13 20:40 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-31 0:38 [PATCH v5 0/3] USB/UVC: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein
2026-03-31 0:38 ` [PATCH v5 1/3] USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam JP Hein
2026-03-31 0:38 ` [PATCH v5 2/3] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile firmware JP Hein
2026-04-09 6:45 ` Ricardo Ribalda
[not found] ` <CAD5VvzAu8+Qz7hEEBzuKvO11X=YD-wrtX3_Tk77g2Cq5rZZD0Q@mail.gmail.com>
2026-04-09 7:51 ` Jeffrey Hein
2026-04-09 8:02 ` Michal Pecio
2026-04-09 8:15 ` Jeffrey Hein
2026-04-09 20:17 ` Michal Pecio
2026-04-10 0:01 ` Jeffrey Hein
2026-04-10 0:24 ` Jeffrey Hein
2026-04-10 4:47 ` Michal Pecio
2026-04-10 21:48 ` Mathias Nyman
2026-04-10 23:06 ` Jeffrey Hein
2026-04-13 8:05 ` Michal Pecio
2026-04-13 20:24 ` Michal Pecio
2026-04-11 13:39 ` Michal Pecio
2026-03-31 0:38 ` [PATCH v5 3/3] media: uvcvideo: add quirks for Razer Kiyo Pro webcam JP Hein
2026-04-09 6:49 ` Ricardo Ribalda
2026-04-09 7:38 ` Jeffrey Hein
2026-04-09 7:42 ` [PATCH v6 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein
2026-04-09 7:42 ` [PATCH v6 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein
2026-04-09 7:57 ` Ricardo Ribalda
2026-04-09 8:12 ` Jeffrey Hein
2026-04-09 7:42 ` [PATCH v6 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table JP Hein
2026-04-09 7:57 ` Ricardo Ribalda
2026-04-09 8:13 ` Jeffrey Hein
2026-04-10 0:28 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure JP Hein
2026-04-10 0:28 ` [PATCH v7 1/2] media: uvcvideo: add UVC_QUIRK_CTRL_THROTTLE for fragile USB firmware JP Hein
2026-04-10 0:28 ` [PATCH v7 2/2] media: uvcvideo: add Razer Kiyo Pro to device info table JP Hein
2026-04-13 20:40 ` [PATCH v7 0/2] media: uvcvideo: Add quirks to prevent Razer Kiyo Pro xHCI cascade failure Michal Pecio
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox