Hello Mathias,
Yes! This fixed the problem. I've checked with our repro case as well as our functional tests.
I'll email you the repro code directly, you can compare the unpatched and patched kernel behavior.
Best regards,
Chris
----- Original Message -----
From: "Mathias Nyman" <mathias.nyman@xxxxxxxxxxxxxxx>
To: "Chris Yokum" <linux-usb@xxxxxxxxxxxxxxxxxxx>, "Greg Kroah-Hartman" <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: "Linux regressions mailing list" <regressions@xxxxxxxxxxxxxxx>, "stable" <stable@xxxxxxxxxxxxxxx>, "linux-usb" <linux-usb@xxxxxxxxxxxxxxx>, "Niklas Neronin" <niklas.neronin@xxxxxxxxxxxxxxx>
Sent: Monday, March 4, 2024 7:53:03 AM
Subject: Re: 6.5.0 broke XHCI URB submissions for count >512
On 4.3.2024 13.57, Mathias Nyman wrote:
> On 2.3.2024 17.55, Chris Yokum wrote:
>>>> We have found a regression bug, where more than 512 URBs cannot be
>>>> reliably submitted to XHCI. URBs beyond that return 0x00 instead of
>>>> valid data in the buffer.
>>>
>>> FWIW, that's f5af638f0609af ("xhci: Fix transfer ring expansion size
>>> calculation") [v6.5-rc1] from Mathias.
>>>
>
> Ok, I see, this could be the empty ring exception check in xhci-ring.c:
>
> It could falsely assume ring is empty when it in fact is filled up in one
> go by queuing several small urbs.
Does this help?
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6a29ebd6682d..52278afea94b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -332,7 +332,13 @@ static unsigned int xhci_ring_expansion_needed(struct xhci_hcd *xhci, struct xhc
/* how many trbs will be queued past the enqueue segment? */
trbs_past_seg = enq_used + num_trbs - (TRBS_PER_SEGMENT - 1);
- if (trbs_past_seg <= 0)
+ /*
+ * Consider expanding the ring already if num_trbs fills the current
+ * segment (i.e. trbs_past_seg == 0), not only when num_trbs goes into
+ * the next segment. Avoids confusing full ring with special empty ring
+ * case below
+ */
+ if (trbs_past_seg < 0)
return 0;
Thanks
Mathias
