Re: [RFT PATCHv3 3/3] xhci: tune urb->start_frame in ring overrun and underrun cases

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 25 May 2026 20:49:15 -0400, Dylan Robinson wrote:
> On Thu, May 21, 2026 at 11:27 AM Mathias Nyman wrote:
> > Make sure a new urb->start_frame is calculated for isoc URBs
> > submitted late mid stream, i.e. isoc URB is submitted to an empty
> > ring after a ring underrun or overrun event.
> >
> > If URB was queud late, but before xhci driver handles the ring
> > underrun/overrun event then kick the urb->start_frame forward by one
> > ESIT for that delayed URB.
> >
> > the gap in urb->start_frame allows class drivers to detect the
> > glitch in isochronous transfers.  
> 
> This does appear to create a detectable gap, but urb->start_frame
> still drifts relative to the actual frame id. After each
> underrun/overrun, urb->start_frame becomes increasingly offset.

That's not surprising, the exact delay is unpredictable, which will
affect drivers that tolarate the gap and continue their stream.

> 
> > +       /* re-calculate urb->start_frame on next urb enqueue */
> > +       if (list_empty(&ep->ring->td_list)) {
> > +               ep->next_uframe = -2; // FIXME define something, or use suitable -EXXX
> > +               ep->skip = false;  // maybe, or is it the wrong place?
> > +               return 0;
> > +       }  
> 
> Since mid-stream URBs can be submitted after an underrun or overrun
> has already occurred, but before the xrun event has been handled, the
> TD list is not necessarily empty here and all subsequent URBs will
> still be scheduled as SIA.

Yes, they have already been written to the ring as SIA. (And if they
weren't SIA, the HW is empirically known to do weird things. The 1.0
spec was weird and so is the HW which implements it).

These URBs will very likely execute in a wrong interval, unless we stop
the endpoint to remove them (which we may fail to do quickly enough)
or completely prevent submissions violating the IST in the first place.

> I think the only way to prevent this drift would be to intentionally
> introduce an additional gap so that the host controller driver can
> restart the stream on a known frame.

If we want to gamble that maybe a slight IST violation will still
succeed anyway, this seems to be the only recovery when we lose.

Either way, we need to fail certain IST-violating submissions with
-EXDEV or complete them immediately with -EXDEV status. Which is what
I was working on and finding various issues with (the driver doesn't
expect queued URBs which aren't written to the ring). Unfortunately,
it still isn't finished as I have little free time currently.

By the way, do you know what Windows does in such cases?

Regards,
Michal