From: Bart Nagel <bart@tremby.net>
To: linux-usb@vger.kernel.org
Cc: mathias.nyman@intel.com, michal.pecio@gmail.com
Subject: Regression: webcam freezing since Linux 6.15
Date: Tue, 21 Jul 2026 15:10:22 -0700 [thread overview]
Message-ID: <al_hchyOdPoPWKEo@spiral> (raw)
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.
next reply other threads:[~2026-07-21 22:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-21 22:10 Bart Nagel [this message]
2026-07-22 22:22 ` Regression: webcam freezing since Linux 6.15 Michal Pecio
2026-07-22 23:23 ` Bart Nagel
2026-07-22 23:30 ` Bart Nagel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=al_hchyOdPoPWKEo@spiral \
--to=bart@tremby.net \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=michal.pecio@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox