From: Guenter Roeck <linux@roeck-us.net>
To: Doug Anderson <dianders@chromium.org>
Cc: "Minas Harutyunyan" <hminas@synopsys.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Antti Seppälä" <a.seppala@gmail.com>,
"Boris ARZUR" <boris@konbu.org>,
linux-usb@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
"Felipe Balbi" <balbi@kernel.org>,
"Stefan Wahren" <stefan.wahren@i2se.com>,
"Martin Schiller" <ms@dev.tdt.de>
Subject: Re: [RFT PATCH 3/4] usb: dwc2: Abort transaction after errors with unknown reason
Date: Thu, 27 Feb 2020 16:36:59 -0800 [thread overview]
Message-ID: <20200228003659.GB11811@roeck-us.net> (raw)
In-Reply-To: <CAD=FV=UMB8=qxAH=9VCZk-g6iFqPpM2RnrekmTXuqcOrHkVuLw@mail.gmail.com>
On Thu, Feb 27, 2020 at 02:06:55PM -0800, Doug Anderson wrote:
> Hi,
>
> On Wed, Feb 26, 2020 at 1:04 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > In some situations, the following error messages are reported.
> >
> > dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown
> > dwc2 ff540000.usb: hcint 0x00000002, intsts 0x04000021
> >
> > This is sometimes followed by:
> >
> > dwc2 ff540000.usb: dwc2_update_urb_state_abn(): trimming xfer length
> >
> > and then:
> >
> > WARNING: CPU: 0 PID: 0 at kernel/v4.19/drivers/usb/dwc2/hcd.c:2913
> > dwc2_assign_and_init_hc+0x98c/0x990
> >
> > The warning suggests that an odd buffer address is to be used for DMA.
> >
> > After an error is observed, the receive buffer may be full
> > (urb->actual_length >= urb->length). However, the urb is still left in
> > the queue unless three errors were observed in a row. When it is queued
> > again, the dwc2 hcd code translates this into a 1-block transfer.
> > If urb->actual_length (ie the total expected receive length) is not
> > DMA-aligned, the buffer pointer programmed into the chip will be
> > unaligned. This results in the observed warning.
> >
> > To solve the problem, abort input transactions after an error with
> > unknown cause if the entire packet was already received. This may be
> > a bit drastic, but we don't really know why the transfer was aborted
> > even though the entire packet was received. Aborting the transfer in
> > this situation is less risky than accepting a potentially corrupted
> > packet.
> >
> > With this patch in place, the 'ChHltd set' and 'trimming xfer length'
> > messages are still observed, but there are no more transfer attempts
> > with odd buffer addresses.
> >
> > Cc: Boris ARZUR <boris@konbu.org>
> > Cc: Douglas Anderson <dianders@chromium.org>
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > ---
> > drivers/usb/dwc2/hcd_intr.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
>
> Seems sane to me. Also suggest a "Fixes" or "Cc: stable" tag.
>
Added:
Fixes: 151d0cbdbe860 ("usb: dwc2: make the scheduler handle excessive NAKs better")
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
Thanks!
Guenter
next prev parent reply other threads:[~2020-02-28 0:37 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 21:04 [RFT PATCH 0/4] usb: dwc2: Fixes and improvements Guenter Roeck
2020-02-26 21:04 ` [RFT PATCH 1/4] usb: dwc2: Simplify and fix DMA alignment code Guenter Roeck
2020-02-27 22:06 ` Doug Anderson
2020-02-27 22:27 ` Guenter Roeck
2020-02-28 4:28 ` Guenter Roeck
2020-02-28 16:14 ` Doug Anderson
2020-02-28 17:59 ` Guenter Roeck
2020-02-29 7:46 ` Antti Seppälä
2020-02-29 15:25 ` Guenter Roeck
2020-02-29 16:33 ` Antti Seppälä
2020-03-01 15:51 ` Antti Seppälä
2020-03-01 16:24 ` Guenter Roeck
2020-03-01 16:51 ` Antti Seppälä
2020-03-01 17:13 ` Guenter Roeck
2020-02-28 16:26 ` Stefan Wahren
2020-02-26 21:04 ` [RFT PATCH 2/4] usb: dwc2: Do not update data length if it is 0 on inbound transfers Guenter Roeck
2020-02-27 22:06 ` Doug Anderson
2020-02-28 0:32 ` Guenter Roeck
2020-02-26 21:04 ` [RFT PATCH 3/4] usb: dwc2: Abort transaction after errors with unknown reason Guenter Roeck
2020-02-27 22:06 ` Doug Anderson
2020-02-28 0:36 ` Guenter Roeck [this message]
2020-02-26 21:04 ` [RFT PATCH 4/4] usb: dwc2: Make "trimming xfer length" a debug message Guenter Roeck
2020-02-27 22:07 ` Doug Anderson
2020-02-28 0:38 ` Guenter Roeck
2020-02-29 1:50 ` [RFT PATCH 0/4] usb: dwc2: Fixes and improvements Boris ARZUR
2021-01-12 19:40 ` Nicolas Saenz Julienne
2021-01-12 19:44 ` Nicolas Saenz Julienne
2021-01-13 4:48 ` Guenter Roeck
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=20200228003659.GB11811@roeck-us.net \
--to=linux@roeck-us.net \
--cc=a.seppala@gmail.com \
--cc=balbi@kernel.org \
--cc=boris@konbu.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=hminas@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=ms@dev.tdt.de \
--cc=stefan.wahren@i2se.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
all inboxes | Powered by JetHome®