Re: Regression: webcam freezing since Linux 6.15

[Bart Nagel <bart@tremby.net>]

At 2026-07-23 00:22:56 +0200, Michal Pecio wrote:
> 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.

Confirmed still on bus 2. That command gives

    0000:00:14.0

> 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.

I'm still on the asterisked kernel from the list above at the moment
(appears to be "good"). I tried enabling this and I do indeed get a
few of those errors and they seem to recover. This is what I have so
far after having set it about 5 minutes ago:

    Jul 22 16:14:07 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:14:07 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:14:07 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:14:07 spiral kernel: xhci_hcd 0000:00:14.0: Found td. Clear skip flag for slot 18 ep 2.
    Jul 22 16:14:52 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:14:53 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:14:53 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:14:53 spiral kernel: xhci_hcd 0000:00:14.0: Found td. Clear skip flag for slot 18 ep 2.
    Jul 22 16:16:06 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:16:06 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:16:06 spiral kernel: xhci_hcd 0000:00:14.0: Found td. Clear skip flag for slot 18 ep 2.
    Jul 22 16:17:33 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:17:33 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:17:33 spiral kernel: xhci_hcd 0000:00:14.0: Miss service interval error for slot 18 ep 2, set skip flag
    Jul 22 16:17:33 spiral kernel: xhci_hcd 0000:00:14.0: Found td. Clear skip flag for slot 18 ep 2.

> > 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.

I will see if I can get a 7.x kernel installed and hopefully it's not
beyond me. At the very least, I'll get back to the latest kernel in
nixos-unstable (which perhaps is 7.x by now anyway). Then I'll enable
the extra debugging as you directed and see what I get in the logs
when it fails. Would the uvcvideo logging be useful or should I skip
that part?

Thank you.