From: Alan Stern <stern@rowland.harvard.edu>
To: Michal Hocko <mhocko@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: kworker/0:3+pm hogging CPU
Date: Tue, 21 Jul 2020 10:33:25 -0400 [thread overview]
Message-ID: <20200721143325.GB1272082@rowland.harvard.edu> (raw)
In-Reply-To: <20200721055917.GD4061@dhcp22.suse.cz>
On Tue, Jul 21, 2020 at 07:59:17AM +0200, Michal Hocko wrote:
> > Sorry, my mistake. The module name needs to be "xhci_hcd" with an '_'
> > character, not a '-' character -- the same as what shows up in the lsmod
> > output.
>
>
> [14766.973734] xhci_hcd 0000:00:14.0: Get port status 2-1 read: 0xe000088, return 0x88
> [14766.973738] xhci_hcd 0000:00:14.0: Get port status 2-2 read: 0xe000088, return 0x88
> [14766.973742] xhci_hcd 0000:00:14.0: Get port status 2-3 read: 0xe0002a0, return 0x2a0
> [14766.973746] xhci_hcd 0000:00:14.0: Get port status 2-4 read: 0xe0002a0, return 0x2a0
> [14766.973750] xhci_hcd 0000:00:14.0: Get port status 2-5 read: 0xe0002a0, return 0x2a0
> [14766.973754] xhci_hcd 0000:00:14.0: Get port status 2-6 read: 0xe0002a0, return 0x2a0
> [14766.973759] xhci_hcd 0000:00:14.0: Get port status 2-1 read: 0xe000088, return 0x88
> [14766.973763] xhci_hcd 0000:00:14.0: Get port status 2-2 read: 0xe000088, return 0x88
According to the xHCI specification, those 02a0 values are normal and
the 0088 values indicate the port is disabled and has an over-current
condition. I don't know about the e000 bits in the upper part of the
word; according to my copy of the spec those bits should be 0.
If your machine has only two physical SuperSpeed (USB-3) ports then
perhaps the other four ports are internally wired in a way that creates
a permanent over-current indication.
> [14766.973771] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 0 status = 0xe000088
> [14766.973780] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 1 status = 0xe000088
> [14766.973789] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 2 status = 0xe0002a0
> [14766.973798] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 3 status = 0xe0002a0
> [14766.973807] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 4 status = 0xe0002a0
> [14766.973816] xhci_hcd 0000:00:14.0: set port remote wake mask, actual port 5 status = 0xe0002a0
> [14766.973830] xhci_hcd 0000:00:14.0: Bus suspend bailout, port over-current detected
>
> Repeating again and again. The last message suggests a HW problem? But
> why does the kernel try the same thing over and over?
Because over-current is supposed to be a transient condition that goes
away quickly. It means there's a short circuit or something similar.
> > You could also try collect a usbmon trace from the .../2u file. It does
> > seem that bus 2 is where the problem occurs.
>
> a random sample
...
> ffff888040808cc0 2551256922 S Ci:2:001:0 s a3 00 0000 0001 0004 4 <
> ffff888040808cc0 2551256925 C Ci:2:001:0 0 4 = 88000000
> ffff888040808cc0 2551256927 S Ci:2:001:0 s a3 00 0000 0002 0004 4 <
> ffff888040808cc0 2551256933 S Ci:2:001:0 s a3 00 0000 0003 0004 4 <
> ffff888040808cc0 2551256936 C Ci:2:001:0 0 4 = a0020000
> ffff888040808cc0 2551256942 C Ci:2:001:0 0 4 = a0020000
...
The usbmon output has a lot of gaps, but here we can see some of the
port status data contains 0x0088 (four bytes little-endian) and some
contains 0x02a0 -- the same as what the debugging log says.
So yes, this looks like a hardware design error. Turning off
autosuspend by writing to the sysfs power/control file is probably the
best way to handle the problem.
Alan Stern
next prev parent reply other threads:[~2020-07-21 14:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-20 8:39 kworker/0:3+pm hogging CPU Michal Hocko
2020-07-20 13:58 ` Alan Stern
2020-07-20 14:32 ` Michal Hocko
2020-07-20 15:12 ` Alan Stern
2020-07-20 16:33 ` Michal Hocko
2020-07-20 17:38 ` Alan Stern
2020-07-20 17:45 ` Michal Hocko
2020-07-20 17:48 ` Alan Stern
2020-07-20 18:16 ` Michal Hocko
2020-07-20 20:02 ` Alan Stern
2020-07-21 5:59 ` Michal Hocko
2020-07-21 14:33 ` Alan Stern [this message]
2020-07-21 16:00 ` Michal Hocko
2020-07-21 16:14 ` Alan Stern
2020-08-29 9:50 ` Salvatore Bonaccorso
2020-08-29 15:59 ` Alan Stern
2020-08-31 11:37 ` Mathias Nyman
2020-09-01 15:27 ` Michal Hocko
2020-09-04 15:57 ` Dirk Kostrewa
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=20200721143325.GB1272082@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=rjw@rjwysocki.net \
/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;
as well as URLs for NNTP newsgroup(s).