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

[Michal Pecio <michal.pecio@gmail.com>]

On Sat, 22 Aug 2026 02:37:28 +0300, Дмитрий wrote:
> At 640x480 YUYV and a requested 30 fps, with
> exposure_dynamic_framerate=1, a normal 120-frame run timed out after
> 45.034 seconds with rc=124.
> 
> With exposure_dynamic_framerate=0, the camera is no longer completely
> stuck, but the video is still not usable as a smooth stream:

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

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

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

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

> * One 120-frame run completed in 15.109 seconds, giving an effective
>    7.94 delivered fps and 304 skipped sequence numbers.
> * Five consecutive restart runs all completed with rc=0, but their
>    effective delivered rates ranged from 3.71 to 21.08 fps.
 
> With uvcvideo trace=0x400, both values of
> exposure_dynamic_framerate selected the same streaming configuration:
> 
> Device requested 3072 B/frame bandwidth
> Selecting alternate setting 7 (3072 B/frame bandwidth)
> Allocated 5 URB buffers of 32x3072 bytes each

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

Regards,
Michal