Re: Regression: webcam freezing since Linux 6.15

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

On Tue, 21 Jul 2026 15:10:22 -0700, Bart Nagel wrote:
> I regularly capture from screen and webcam while gaming. Usually it is
> rock solid, and can capture for hours and hours with no problems, and
> have done for hundreds of hours in total.
> 
> After a kernel update from 6.12.83 to 6.18.28 I started getting webcam
> freezes. The symptom is that the picture from the camera suddenly
> stops changing and will stay as a freeze frame. The camera still
> claims to be active, and the capture software (tried with OBS and
> ffplay) seems to have no idea anything is wrong.
> 
> I have found no reliable way to reproduce the problem other than
> running the system at high load (in particular running a game;
> problem occurs across multiple games) while capturing from webcam. In
> my tests so far it has taken anywhere between 8 minutes and a couple
> of hours to fail in these conditions. Freezes seem to be less common
> when the system is under less load -- for example I have tried
> leaving it running overnight when the system is under low load and
> seen no freeze, then I have started a game and seen a freeze within
> the next hour. I have no way of knowing whether no freeze is a pass
> or it's just that a failure didn't quite happen yet so I have been
> testing for many hours while bisecting, often over the course of a
> whole week or more.
> 
> My bisection took me to a USB branch leading up to the release of
> 6.15. Specifically:
> 
> ddd0172f182e pass (branch point of USB branch, "Merge tag 'tty-6.15-rc1'
>              of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty")
> a1b5bd45d4ee fail (merge of USB branch, "Merge tag 'usb-6.15-rc1' of
>              git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb")
> 
> Digging deeper in that branch, these are my results during bisecting
> (sorted into graph order):
> 
> 6623c40bed7a pass (usb: storage: datafab: Use const for constant arrays)
> bfa845994282 pass (usb: xhci: Complete 'error mid TD' transfers when
>              handling Missed Service)
> 906dec15b9b3 pass* (usb: xhci: Fix isochronous Ring Underrun/Overrun event
>              handling)
> d0b619599e52 fail (usb: xhci: Expedite skipping missed isoch TDs on modern
>              HCs)
> fe1ccba52a8d fail (usb: xhci: Skip only one TD on Ring Underrun/Overrun)
> d71cb7d6e1a2 fail (usb: xhci: refactor trb_in_td() to be static)
> 525b139fb403 fail (Merge v6.14-rc6 into usb-next)
> 
> The asterisk with 906dec15b9b3 is because it has survived 12+ hours of
> recording while gaming so far but I did see the webcam freeze once at
> the precise moment I made some changes in OBS. After resetting it I
> recorded for another 6+ hours with no issues. The other failures have
> been much faster and occurred at seemingly random times, so I'm not
> 100% sure here.

It might be that you have two different problems. Another user of Razer
Kiyo Pro reported that tweaking camera settings causes some failures,
so this may be unrelated to your main issue.

> If I take that one as a pass, the bisection points to commit
> d0b619599e52fe3e1454f7d151dedf2b194f61d8 as the first failing: "usb: xhci:
> Expedite skipping missed isoch TDs on modern HCs"

That's what it seems and it's weird.

> At the moment of failure I have seen a huge flood of duplicates of this
> message in dmesg:
> 
>     uvcvideo 2-6.1:1.0: USB isochronous frame lost (-18)
> 
> This happened during some bisection steps but not all. Regrettably I did
> not record which steps produced the error and which did not. In fact, I
> think during the weeks of bisecting I remember at same point following
> some advice from an LLM, and it could be that in those cases where I saw
> those messages I'd enabled some extra debugging of some kind, possibly via
> `echo 0xff > sys/module/uvcvideo/parameters/trace`.

Yes, these are debug messages from uvcvideo. They indicate that isoc
transfers completed with -EXDEV status, which is due to Missed Service
Error events from the HW or due to being "skipped".

I don't see any way xhci-hcd could end up skipping forever and never
clearing the skip flag. And it's equally unclear why the HW would begin
generating MSEs forever because we handle them faster than in the past.

What's the affected xHCI controller? You can find its PCI address with
cat /sys/bus/usb/devices/usb2/serial
and then use lspci. Make sure that the camera is stil on bus 2 - these
numbers sometimes change after reboot.


I wonder what happens when you enable some xhci-hcd debugging too?

echo 'func handle_tx_event +p' >/proc/dynamic_debug/control

You will probably see Missed Service Errors being logged occasionally,
likely both on "good" and "bad" kernels. And it seems that good ones
will recover every time, but not sure about bad ones. Does the first
MSE break things forever? Or does it take a few? Could you post a log
when it breaks? Caution: you may see thousands of lines per second.

> The most recent kernel I have tested on is 6.18.28, and the failure
> happens there too.

Some recent 7.x may be worth trying too, if possible, though I won't be
surprised if it's the same as 6.18.

Regards,
Michal