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

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220748

--- Comment #16 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to Alan Stern from comment #15)
> When the queue underruns is exactly when URB_ISO_ASAP is supposed to matter.
> If the flag is set in the new URB then that URB should be scheduled for the
> first slot in the future, leaving a logical gap in the queue.  If the flag
> is clear then the new URB is supposed to be scheduled for the slot that
> follows the preceding URB
I meant cases when the queue empties completely and there is no preceding URB.

But I see that there is a subtle difference in EHCI - it still considers a new
submission to be continuation of the earlier stream if earlier URBs have been
given back but their completion callbacks are still running. We can do it too.

But the real bug is xhci_get_isoc_frame_id(). This should convert
urb->start_frame and packet index into frame_id to be passed to HW, but it also
reschedules URBs which it doesn't like (and does some nonsense if the queue
gets too long).

This happens silently under normal conditions and the warnings at the end of
this function are bogus, almost impossible to trigger. So that's why no one
noticed. The only indicator is urb->start_frame discontinuity, but it seems
that class drivers trust HCDs and aren't validating that.

I don't know if that's the cause of those Motu issues, but it's clearly
involved in the other problem with low-latency duplex operation on CFC
controllers which was reported last year and which I can repro on my HW.

The above applies to xHCI 1.1 controllers (typically USB 3.1 and newer). On
older ones urb->start_frame returned to drivers is kinda bogus and everything
goes ASAP. Which actually seems to work better in most cases than the buggy CFC
stuff, but gaps due to late submission remain undetected.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.