Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load
hi Dirk,
On Wed, Aug 12, 2020 at 05:53:57PM +0200, Dirk Kostrewa wrote:
> Hi Salvatore,
>
> I just found out, that if none of the two USB ports is connected, there are
> two kworker processes with permanently high CPU load, if one USB port is
> connected and the other not, there is one such kworker process, and if both
> USB ports are connected, there is no kworker process with high CPU load.
> I think, this supports your suspicion that these kworker processes are
> connected with the overcurrent condition for both USB ports that I also see
> in the dmesg output.
> What puzzles me, is that I've observed these oddly behaving kworker
> processes also with the 5.6 kernel that I've tried from the Buster Backports
> repository.
The kernel parameter variant did not work correctly as there are no
dynamic debug output afaics (the double quotes seem to placed in the
wrong place), please just try the setting at runtime instead:
# echo 'file drivers/usb/* +p;' > /sys/kernel/debug/dynamic_debug/control
What I was meaning is (and this is confirmed if you see the issue
issue as well with the more recent kernels), that the specified commit
actually uncovers the issue present possibly with the HW.
Similarly to you someone else, where in known case with faulty HW,
reported the following issue upstream:
https://lore.kernel.org/lkml/20200720083956.GA4074@dhcp22.suse.cz/
I would like to see if we can collect as much information as possible
and possibly crosscheck with upstream.
If build the kernel with the attached patch (that is with the commit
wich is supsected to uncover the issue), does then the issue goes
away?
You can folllow the quide in
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
for the "simple patching and building" and quickly chekcing a patch.
Regards,
Salvatore
>From 61ca5460d93d1a60a9aee0e46d51ae126593fda2 Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso <carnil@debian.org>
Date: Fri, 28 Aug 2020 16:31:04 +0200
Subject: [PATCH] Revert "xhci: prevent bus suspend if a roothub port detected
a over-current condition"
This reverts commit d3ee95dedd88ed3fcd4647e4a8e265acaf27b2f0.
---
drivers/usb/host/xhci-hub.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a58ef53e4ae1..eb4284696f25 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1481,8 +1481,6 @@ int xhci_hub_status_data(struct usb_hcd *hcd, char *buf)
}
if ((temp & PORT_RC))
reset_change = true;
- if (temp & PORT_OC)
- status = 1;
}
if (!status && !reset_change) {
xhci_dbg(xhci, "%s: stopping port polling.\n", __func__);
@@ -1548,13 +1546,6 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
port_index);
goto retry;
}
- /* bail out if port detected a over-current condition */
- if (t1 & PORT_OC) {
- bus_state->bus_suspended = 0;
- spin_unlock_irqrestore(&xhci->lock, flags);
- xhci_dbg(xhci, "Bus suspend bailout, port over-current detected\n");
- return -EBUSY;
- }
/* suspend ports in U0, or bail out for new connect changes */
if ((t1 & PORT_PE) && (t1 & PORT_PLS_MASK) == XDEV_U0) {
if ((t1 & PORT_CSC) && wake_enabled) {
--
2.28.0
Reply to: