From: jwerner@chromium.org (Julius Werner)
To: linux-arm-kernel@lists.infradead.org
Subject: usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
Date: Mon, 16 Oct 2017 13:49:11 -0700 [thread overview]
Message-ID: <CAODwPW8qtw0qVxUGJUNt2H8TTCOEvn6G9qbUBi6_MKWgeAwcaQ@mail.gmail.com> (raw)
In-Reply-To: <446301756.220218.1494678481761@email.1und1.de>
> d9a14b00 339317035 C Ii:1:004:1 -32:1 0
> d9a14b00 339317049 S Ii:1:004:1 -115:1 10 <
> d9a14b00 339318040 C Ii:1:004:1 -32:1 0
> d9a14b00 339318057 S Ii:1:004:1 -115:1 10 <
> d9a14b00 339319042 C Ii:1:004:1 -32:1 0
> d9a14b00 339319056 S Ii:1:004:1 -115:1 10 <
> d9a14b00 339329551 C Ii:1:004:1 -32:1 0
> d9a14b00 339329571 S Ii:1:004:1 -115:1 10 <
> d9a14b00 339330586 C Ii:1:004:1 -32:1 0
> d9a14b00 339330601 S Ii:1:004:1 -115:1 10 <
> d9a14b00 339331035 C Ii:1:004:1 -32:1 0
Sorry for necromancing an old thread, but I just happened to read
through this and thought someone might care:
If I read that right, the usbmon output shows that the interrupt
endpoint is stalled (keeps returning -EPIPE). A STALL is a special
device-side USB condition that tells the host something is wrong and
will persist until cleared manually. It seems that the driver isn't
prepared for this (see
drivers/usb/serial/pl2303.c#pl2303_read_int_callback) and just keeps
resubmitting the URB, so it will stall again as fast as the endpoint
allows it to. This may be the reason why you get so many transfers
that it overwhelms the CPU.
A fix would be to catch -EPIPE in that function and handle it
explicitly (with either a CLEAR_STALL to the endpoint or a full USB
reset... would have to look at the documentation for PL2303 to see
what the stall actually means and how you're supposed to treat it).
next prev parent reply other threads:[~2017-10-16 20:49 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-31 20:34 usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s Stefan Wahren
2016-11-01 8:26 ` Michael Zoran
2017-04-17 11:05 ` Stefan Wahren
2017-04-17 22:37 ` Doug Anderson
2017-04-18 8:07 ` Stefan Wahren
2017-04-18 20:08 ` Doug Anderson
2017-04-18 20:25 ` Stefan Wahren
2017-04-18 20:41 ` Doug Anderson
2017-04-18 20:53 ` Stefan Wahren
2017-04-19 20:25 ` Stefan Wahren
2017-04-19 21:47 ` Doug Anderson
2017-04-20 7:46 ` Stefan Wahren
2017-04-20 16:19 ` Doug Anderson
2017-04-20 18:54 ` Eric Anholt
2017-04-20 19:45 ` Doug Anderson
2017-04-20 19:57 ` Eric Anholt
2017-04-20 20:37 ` Doug Anderson
2017-04-22 20:50 ` Stefan Wahren
2017-04-25 18:11 ` Stefan Wahren
2017-05-08 20:22 ` Stefan Wahren
2017-05-10 16:31 ` Johan Hovold
2017-05-10 23:50 ` Doug Anderson
2017-05-13 12:28 ` Stefan Wahren
2017-10-16 20:49 ` Julius Werner [this message]
2017-10-17 8:52 ` Johan Hovold
2017-10-25 21:22 ` Doug Anderson
2017-04-19 8:56 ` Johan Hovold
2017-04-19 9:12 ` Stefan Wahren
2017-04-19 9:55 ` Johan Hovold
2017-04-17 23:45 ` Heiko Stuebner
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=CAODwPW8qtw0qVxUGJUNt2H8TTCOEvn6G9qbUBi6_MKWgeAwcaQ@mail.gmail.com \
--to=jwerner@chromium.org \
--cc=linux-arm-kernel@lists.infradead.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.