From: "Michał Pecio" <michal.pecio@gmail.com>
To: mathias.nyman@linux.intel.com, niklas.neronin@linux.intel.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH 10/12] usb: xhci: adjust empty TD list handling in handle_tx_event()
Date: Fri, 6 Sep 2024 14:23:16 +0200 [thread overview]
Message-ID: <20240906142316.3b00e4f1@foxbook> (raw)
In-Reply-To: <20240905143300.1959279-11-mathias.nyman@linux.intel.com>
>@@ -2761,35 +2761,25 @@ static int handle_tx_event(struct xhci_hcd *xhci,
> return 0;
> }
>
>- do {
>- /* This TRB should be in the TD at the head of this ring's
>- * TD list.
>+ if (list_empty(&ep_ring->td_list)) {
>+ /*
>+ * Don't print wanings if ring is empty due to a stopped endpoint generating an
>+ * extra completion event if the device was suspended. Or, a event for the last TRB
Is changing this code perhaps an opportunity to clarify its comments?
This is just confusing. A stopped endpoint doesn't generate any "extra"
events since it can't be stopped again. Commit message of a83d6755814e4
suggests that this was about stopping running but idle EPs (as is the
case of EP0 before suspend). So briefly and to the point:
/* Ignore Force Stopped Event on an empty ring,
or one containing only NOPs and Links */
>+ * of a short TD we already got a short event for. The short TD is already removed
>+ * from the TD list.
> */
>- if (list_empty(&ep_ring->td_list)) {
>- /*
>- * Don't print wanings if it's due to a stopped endpoint
>- * generating an extra completion event if the device
>- * was suspended. Or, a event for the last TRB of a
>- * short TD we already got a short event for.
>- * The short TD is already removed from the TD list.
>- */
>-
>- if (!(trb_comp_code == COMP_STOPPED ||
>- trb_comp_code == COMP_STOPPED_LENGTH_INVALID ||
>- ep_ring->last_td_was_short)) {
>- xhci_warn(xhci, "WARN Event TRB for slot %u ep %d with no TDs queued?\n",
>- slot_id, ep_index);
>- }
>- if (ep->skip) {
>- ep->skip = false;
>- xhci_dbg(xhci, "td_list is empty while skip flag set. Clear skip flag for slot %u ep %u.\n",
>- slot_id, ep_index);
>- }
>-
>- td = NULL;
>- goto check_endpoint_halted;
>+ if (trb_comp_code != COMP_STOPPED &&
>+ trb_comp_code != COMP_STOPPED_LENGTH_INVALID &&
>+ !ep_ring->last_td_was_short) {
>+ xhci_warn(xhci, "Event TRB for slot %u ep %u with no TDs queued\n",
>+ slot_id, ep_index);
I would add trb_comp_code here if touching this line.
> }
>
>+ ep->skip = false;
I don't like that the xhci_dbg() has been removed. If skip debugging is
to be reliable, it should report all state transitions. And this is an
unusual one, so maybe very interesting. Skip debugging is valuable, as
the logic is tricky and has known problem cases. More below.
>+ goto check_endpoint_halted;
>+ }
>+
>+ do {
> td = list_first_entry(&ep_ring->td_list, struct xhci_td,
> td_list);
>
>@@ -2800,7 +2790,14 @@ static int handle_tx_event(struct xhci_hcd *xhci,
>
> if (ep->skip && usb_endpoint_xfer_isoc(&td->urb->ep->desc)) {
> skip_isoc_td(xhci, td, ep, status);
>- continue;
>+ if (!list_empty(&ep_ring->td_list))
>+ continue;
>+
>+ xhci_dbg(xhci, "All TDs skipped for slot %u ep %u. Clear skip flag.\n",
>+ slot_id, ep_index);
This used to get the empty list warning, but now it's mere xhci_dbg().
Throwing out all queued TDs is not the common case and it may easily
be a bug. Indeed, I can readily name two cases when it is a bug today:
1. Force Stopped Event on a NOP or Link following the missed TD. Then
trb_in_td() doesn't match subsequent TD and the rest is trashed.
Actually, this is a v6.11 regression since d56b0b2ab1429. Although past
behavior was bad and broken too, it was broken differently.
2. Ring Underrun/Overrun if new TDs were queued before we handled it.
If ep_trb_dma is NULL, nothing ever matches and everything goes out.
Arguably, these are rare events and I haven't observed them yet.
And one more problem that I don't think currently exists, but:
3. If you ever find yourself doing it on an ordinary event (Success,
Transaction Error, Babble, etc.) then, seriously, WTF?
Bottom line, empty list is a very suspicious thing to see here. I can
only think of two legitimate cases:
1. Ring X-run, only if nothing new was queued since it occurred.
2. FSE outside transfer TDs, if no transfer TDs existed after it.
>+ ep->skip = false;
>+ td = NULL;
>+ goto check_endpoint_halted;
Isoch EPs can't stall and aren't supposed to halt on errors, 4.10.2.
> }
>
> /*
next prev parent reply other threads:[~2024-09-06 12:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 14:32 [PATCH 00/12] xhci features for usb-next Mathias Nyman
2024-09-05 14:32 ` [PATCH 01/12] xhci: dbc: Fix STALL transfer event handling Mathias Nyman
2024-09-05 14:32 ` [PATCH 02/12] xhci: dbc: add dbgtty request to end of list once it completes Mathias Nyman
2024-09-05 14:32 ` [PATCH 03/12] xhci: Remove unused function declarations Mathias Nyman
2024-09-05 14:32 ` [PATCH 04/12] usb: xhci: remove excessive isoc frame debug message spam Mathias Nyman
2024-09-05 21:30 ` Thinh Nguyen
2024-09-06 13:27 ` Mathias Nyman
2024-09-07 0:41 ` Thinh Nguyen
2024-09-05 14:32 ` [PATCH 05/12] usb: xhci: remove excessive Bulk short packet debug message Mathias Nyman
2024-09-05 14:32 ` [PATCH 06/12] usb: xhci: remove unused variables from struct 'xhci_hcd' Mathias Nyman
2024-09-05 14:32 ` [PATCH 07/12] usb: xhci: make 'sbrn' a local variable Mathias Nyman
2024-09-05 14:32 ` [PATCH 08/12] usb: xhci: add comments explaining specific interrupt behaviour Mathias Nyman
2024-09-05 14:32 ` [PATCH 09/12] usb: xhci: remove 'retval' from xhci_pci_resume() Mathias Nyman
2024-09-05 14:32 ` [PATCH 10/12] usb: xhci: adjust empty TD list handling in handle_tx_event() Mathias Nyman
2024-09-06 4:44 ` fps
2024-09-06 7:09 ` Neronin, Niklas
2024-09-06 12:23 ` Michał Pecio [this message]
2024-09-06 13:05 ` Neronin, Niklas
2024-09-09 8:22 ` Michał Pecio
2024-09-05 14:32 ` [PATCH 11/12] xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them Mathias Nyman
2024-09-05 14:33 ` [PATCH 12/12] xhci: support setting interrupt moderation IMOD for secondary interrupters 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=20240906142316.3b00e4f1@foxbook \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=niklas.neronin@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox