public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michał Pecio" <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [RFT PATCH] xhci: process isoc TD properly when there was an error mid TD.
Date: Wed, 17 Jan 2024 18:49:05 +0100	[thread overview]
Message-ID: <20240117184905.1800b1cc@foxbook> (raw)
In-Reply-To: <f6542354-d6d1-be22-82ed-5dfa57aa8337@linux.intel.com>

> But yes, if the last TD in a URB is a multi TRB isoc TD, and it has
> an error MID TD then its stuck until timeout.

If there are timeouts to deal with hosts failing to respond then that's
good enough for me. It should be a rare case anyway.

I just don't like when stuff locks up forever and requires reconnection
or reboot to clean up.


> > Would it be possible to retire the TD right after the first failed
> > TRB?
> 
> Probably not as a normal error handling routine.
> We have the same "Transfer event TRB DMA ptr not part of current TD"
> issue for hosts that do issue an event for the last TRB.

Obviously it would require keeping some information about the retired
TD to detect subsequent completions and to prevent freeing of its
remaining TRBs. Probably much more effort than the current approach.
 
> But for that special case where there are no more TDs queued it might
> make sense

Wouldn't it still require remembering not to free the TRBs too fast?
(It seems to have worked in the early days, but feels dodgy).


> +					xhci_dbg(xhci, "Missing completion event after mid TD error\n");
On second thought, this could also print ep_trb_dma to be useful in
debugging "TRB not part of current TD" issues. Although anyone able to
compile the kernel with DYNAMIC_DEBUG could also edit as necessary...

  reply	other threads:[~2024-01-17 17:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-12 22:52 "Transfer event TRB DMA ptr not part of current TD" spam after USB disconnection Michał Pecio
2024-01-13 20:47 ` Michał Pecio
2024-01-14 14:06   ` Michał Pecio
2024-01-15 13:58     ` Mathias Nyman
2024-01-15 16:27       ` Michał Pecio
2024-01-16 15:36         ` [RFT PATCH] xhci: process isoc TD properly when there was an error mid TD Mathias Nyman
2024-01-16 22:20           ` Michał Pecio
2024-01-17 10:46             ` Mathias Nyman
2024-01-17 17:49               ` Michał Pecio [this message]
2024-01-18 11:00                 ` Isochronous error handling bug on VIA VL805 Michał Pecio
2024-01-18 11:10                   ` Michał Pecio
2024-01-18 13:54                   ` Mathias Nyman
2024-01-18 13:56                     ` [RFT PATCH v2] xhci: process isoc TD properly when there was an error mid TD Mathias Nyman
2024-01-18 22:16                       ` Michał Pecio
2024-01-19 10:49                         ` Mathias Nyman
2024-01-19 10:58                           ` [RTF PATCH v3] " Mathias Nyman
2024-01-19 21:54                             ` Michał Pecio
2024-01-22  9:03                               ` Michał Pecio
2024-01-22 13:37                                 ` Mathias Nyman
2024-01-22 17:10                                   ` Michał Pecio
2024-01-22 11:47                               ` 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=20240117184905.1800b1cc@foxbook \
    --to=michal.pecio@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@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