From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Chris Yokum <linux-usb@mail.totalphase.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linux regressions mailing list <regressions@lists.linux.dev>,
stable <stable@vger.kernel.org>,
linux-usb@vger.kernel.org,
Niklas Neronin <niklas.neronin@linux.intel.com>
Subject: Re: 6.5.0 broke XHCI URB submissions for count >512
Date: Mon, 4 Mar 2024 13:57:32 +0200 [thread overview]
Message-ID: <a6a04009-c3fe-e50d-d792-d075a14ff825@linux.intel.com> (raw)
In-Reply-To: <278587422.841245.1709394906640.JavaMail.zimbra@totalphase.com>
On 2.3.2024 17.55, Chris Yokum wrote:
>
> The submission of >512 URBs is via usbfs, yes. This worked forever, and still works on EHCI, it's just been failing on xHCI once the indicated change was applied.
>
>>> 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.
>>
>>> Attached is a test program that demonstrates the problem. We used a few
>>> different USB-to-Serial adapters with no driver installed as a
>>> convenient way to reproduce. We check the TRB debug information before
>>> and after to verify the actual number of allocated TRBs.
>
Could you send me that test program as well?
> Ah, so this is just through usbfs?
>
>>> With some adapters on unaffected kernels, the TRB map gets expanded
>>> correctly. This directly corresponds to correct functional behavior. On
>>> affected kernels, the TRB ring does not expand, and our functional tests
>>> also will fail.
>>>
>>> We don't know exactly why this happens. Some adapters do work correctly,
>>> so there seems to also be some subtle problem that was being masked by
>>> the liberal expansion of the TRB ring in older kernels. We also saw on
>>> one system that the TRB expansion did work correctly with one particular
>>> adapter. However, on all systems at least two adapters did exhibit the
>>> problem and fail.
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.
static unsigned int xhci_ring_expansion_needed(struct xhci_hcd *xhci, struct xhci_ring *ring,
unsigned int num_trbs)
{
...
/* Empty ring special case, enqueue stuck on link trb while dequeue advanced */
if (trb_is_link(ring->enqueue) && ring->enq_seg->next->trbs == ring->dequeue)
return 0;
...
}
https://elixir.bootlin.com/linux/v6.7/source/drivers/usb/host/xhci-ring.c#L333
Can you help me test some patches on your setup?
Thanks
Mathias
next prev parent reply other threads:[~2024-03-04 11:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-02 0:27 6.5.0 broke XHCI URB submissions for count >512 Chris Yokum
2024-03-02 6:53 ` Linux regression tracking (Thorsten Leemhuis)
2024-03-02 7:14 ` Greg Kroah-Hartman
2024-03-02 15:55 ` Chris Yokum
2024-03-04 11:57 ` Mathias Nyman [this message]
2024-03-04 15:53 ` Mathias Nyman
2024-03-04 23:50 ` Chris Yokum
2024-03-11 17:03 ` Chris Yokum
2024-03-12 8:52 ` Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a6a04009-c3fe-e50d-d792-d075a14ff825@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@mail.totalphase.com \
--cc=linux-usb@vger.kernel.org \
--cc=niklas.neronin@linux.intel.com \
--cc=regressions@lists.linux.dev \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.