Regression: webcam freezing since Linux 6.15

Regression: webcam freezing since Linux 6.15

[Bart Nagel]

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.

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"

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`. Or perhaps those
messages were introduced at some point in the kernel changes. What I do
have recorded is seeing a steady stream of "Frame complete (EOF found)"
messages during normal operation (possibly with extra debug logging
enabled) which would suddenly cut at failure time and be replaced with
those "frame lost" messages. There was no disconnect event at or after
failure; the camera's runtime_status still shows "active" after the
failure.

If it would be useful, I could go back to failing versions and try again,
but for me it is a painfully slow process to build the kernels (I am on
NixOS and I have not yet figured out how to get ccache working so it is
building everything from scratch each time), so I'll only do this if
directed to.

The affected webcam is a Razer Kiyo Pro (1532:0e05). It is connected to a
USB 3 port and is the only device on that host controller (bus 002,
xhci_hcd, 5000M).

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

Please let me know anything I can do to provide useful information, or if
there's anything I can try which might prevent the freezes on current
kernels.

Thanks.

Re: Regression: webcam freezing since Linux 6.15

[Michal Pecio]

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

Re: Regression: webcam freezing since Linux 6.15

[Bart Nagel]

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.