Re: Regression: webcam freezing since Linux 6.15

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.