Re: [Bug 220748] usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set

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

On Fri, 8 May 2026 13:20:04 -0400, Dylan Robinson wrote:
> Our High Speed and SuperSpeed devices always use a bInterval of 1, so
> they expect transfers in every microframe. I'm less familiar with the
> behavior and expectations of endpoints that use larger polling
> intervals.
> 
> Perhaps, rather than treating this as a "specified start frame", it
> would be better to think of it as a "specified start service
> interval".
> 
> If a driver requests a start frame that is not specifically available
> within the periodic schedule, it seems reasonable for the HCD to place
> the transfer at another valid position within that same service
> interval. The actual start frame used could then still be reported
> back through the completed URB, which can be inspected by the driver
> if it needs to know the precise scheduling decision.

IDK if drivers ever need to know. They better not, because there is
no way to get "phase" information out of xHCI, besides timing IRQs.
There is also no way to set it. And no way to schedule a new stream
not on frame boundary. See xHCI 4.11.2.5.1, the rules are simple.

The urb->start_frame you get is the first (u)frame of target interval.
Requests from drivers would need to be rounded, ignored or rejected.

> > It's always possible to observe these errors after the fact
> > (assuming the start_frame values are reliable).  I'm not sure what
> > value there is in observing them when the URB is submitted,
> > however.  What would the driver do differently in these two cases?  
> 
> I agree the two cases are quite similar in terms of observability.
> 
> The main practical benefit of detecting this at submission time might
> be the potential to reduce recovery latency. If the driver can
> determine immediately that scheduling has failed, it may be able to
> restart or resynchronize the stream sooner, which for an audio
> interface, could translate to a smaller audible glitch.

I believe gaps between URBs are not supposed to be happening at all
with proper resubmission, according to documented rules, so drivers
can detect gaps by watching for EXDEV status in frame_desc, if we
manage to bring xhci-hcd into compliance with the rules.

As for predicting EXDEV at submission, it's a gable. We can only be
100% sure whether it's too late or not when the interval completes
with Missed Service or Success.

Admittedly if it fails, the driver unfortunately only learns about
it after the end of the whole URB. Short URBs could be better here.

We can predict it by looking at the Isochronous Scheduling Threshold
reported by the HC, but it's a single number which may not accurately
reflect all cases (full-speed devices behind high-speed hubs are a
fascinating topic) and IME it's quite pessimistic on many chips - in
reality, they can do better than they claim.

So being conservative and failing submissions which missed the IST
might cause a driver to panic and reset the endpoint when no glitch
would actually occur. And of course delaying such URBs (as currently
done) has the known effects that this bug is about.

I wrote some experimental patches to debug and fix this back then,
but nobody was commenting on the bug so I dropped this topic because
I'm reluctant to submit significant changes without real testing.
I can rehash this stuff.

The most important question is if actual HW properly handles URBs
submitted too late. It would be nice to get testing on various xHCI
chips from varous vendors. If there are problems, it could prove
necessary to detect late submissions and complete such transfers as
EXDEV witout HW involvemnet. Yuck. Maybe it won't come to that.

Regards,
Michal