Re: Regression: webcam freezing since Linux 6.15

At 2026-08-05 22:36:04 +0200, Michal Pecio wrote:
> On Wed, 5 Aug 2026 12:01:47 -0700, Bart Nagel wrote:
> > At 2026-07-30 23:59:53 +0200, Michal Pecio wrote:
> > > On Thu, 30 Jul 2026 11:13:59 -0700, Bart Nagel wrote:  
> > > > At 2026-07-30 13:08:14 +0200, Michal Pecio wrote:  
> > > > > I'm slightly curious what exactly happens there (probably MSE after
> > > > > Short Packet on a single-TRB TD), and whether Missed Service Error
> > > > > may point at a Link TRB, because the current fix wouldn't handle
> > > > > that and the stream could still hang. So your failure rate may
> > > > > actually be reduced to 1/255 of what it was, but still not zero.
> > > > > 
> > > > > If possible, please boot the patched kernel again and run it for
> > > > > a little longer. If it fails, post dmesg starting from the "Miss
> > > > > service interval error" line which is followed by "All TDs skipped".
> > > > > 
> > > > > And while that is running, also collect another log:
> > > > > 
> > > > > cd /sys/kernel/tracing/
> > > > > echo 1 > events/xhci-hcd/xhci_handle_event/enable
> > > > > echo 1 > tracing_on
> > > > > grep -B5 Missed trace_pipe | tee /tmp/trace
> > > > > 
> > > > > This is supposed to log 6 lines for every Missed Service Error, so
> > > > > it will grow, but not terribly fast.    
> > > > 
> > > > Before I make a bad assumption and collect a useless log, please
> > > > confirm for me exactly which debugging I should enable. Just the two
> > > > you gave above, or also one or both of the ones I was using before:
> > > > 
> > > >     echo "func handle_tx_event +p" >/proc/dynamic_debug/control
> > > >     echo 0xff >/sys/module/uvcvideo/parameters/trace  
> > > 
> > > Yes, please keep handle_tx_event, otherwise xhci_hcd debug messages
> > > won't show up. UVC trace is not that important.  
> > 
> > OK. I ran it with your temporary patch for around 24 hours with heavy
> > system load and didn't get any freezes. The logs are large; please let
> > me know if there's anything I can grep for which might tell us that
> > the potential 1/255 chance of a freeze still being possible is ruled
> > out.
> 
> Maybe stat with a sample of 100 events (thats 700 lines including ---
> separators added by grep) from "grep -B5 Missed trace_pipe".
> 
> I mainly wanted to see if it's a reliable pattern that the suspicious
> pointers are always 0x10 past the previous event's pointer.
> 
> And what happens when the previous event is at the end of a segment
> (TRB pointer ends with 0xfe0), can we get Missed Service ending with
> 0xff0? The old patch wouldn't handle it, though the new one will.

OK. Attached are the first ~700 lines of the trace file.

That whole thing is 17M, and is here for 48 hours from now in case it
is more illuminating: https://tmpfiles.org/wAwAIQxuuahs/trace.txt

In the dmesg log (2.4G) I grepped for anything looking like an address
ending fe0 or ff0. No ff0 in it. Lots of fe0. Mostly lines like

    [35493.248486] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000010aea6fe0, comp_code 13 after 13
    [35493.482230] xhci_hcd 0000:00:14.0: Spurious event dma 0x000000010aea7fe0, comp_code 13 after 13

And also some of these:

    [83974.976001] xhci_hcd 0000:00:14.0: Miss service interval error for slot 7 ep 2 ep_trb_dma 10aea7fe0 td_dma 10aea7fd0, set skip flag
    [94458.133128] xhci_hcd 0000:00:14.0: Miss service interval error for slot 7 ep 2 ep_trb_dma 10aea6fe0 td_dma 10aea6fd0, set skip flag

Though I suppose those are probably also covered by the other log.

Let me know if I can help further.