Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load

[Dirk Kostrewa <dirk.kostrewa@mailbox.org>]

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.

Cheers,

Dirk.

Am 12.08.20 um 13:02 schrieb Dirk Kostrewa:
> Hi Salvatore,
>
> yesterday, I installed the kernel 5.6.0 from the Buster Backports and 
> saw again a kworker process with high CPU load.
> Oddly, this morning, my laptop didn't boot, so I decided to do a fresh 
> install of Debian Buster 10.5.0 (image with non-free firmware because 
> of my wifi card) and installed only thunderbird and vim. There is 
> still one kworker process with permanently high CPU load.
>
> I gave the dyndbg command that you told me as a kernel parameter upon 
> booting and have appended the dmesg output as file dmesg.txt.gz.
>
> Cheers,
>
> Dirk.
>
> Am 11.08.20 um 21:21 schrieb Salvatore Bonaccorso:
> > Hi Dirk,
> >
> > On Tue, Aug 11, 2020 at 12:58:15PM +0200, Dirk Kostrewa wrote:
> > > Hi Salavatore,
> > >
> > > as an additional control, I have completely uninstalled the nvidia 
> > > graphics
> > > driver and repeated the kworker observations using the nouveau graphics
> > > driver with the kernel 4.19.0-10-amd64. This time, there are even two
> > > kworker processes constantly running with high CPU load:
> > >
> > > $ top
> > > top - 12:37:20 up 10 min,  4 users,  load average: 2.79, 2.54, 1.56
> > > Tasks: 197 total,   3 running, 194 sleeping,   0 stopped,   0 zombie
> > > %Cpu(s):  0.0 us, 24.2 sy,  0.0 ni, 74.2 id,  0.0 wa, 0.0 hi, 1.6 
> > > si,  0.0
> > > st
> > > MiB Mem :  15889.4 total,  13964.7 free,    626.8 used, 1297.9 
> > > buff/cache
> > > MiB Swap:      0.0 total,      0.0 free,      0.0 used. 14849.1 
> > > avail Mem
> > >
> > >    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM TIME+ 
> > > COMMAND
> > >    164 root      20   0       0      0      0 R  80.0 0.0 8:41.67
> > > kworker/6:2+pm
> > >    455 root      20   0       0      0      0 R  80.0 0.0 8:28.23
> > > kworker/2:2+pm
> > >     22 root      20   0       0      0      0 S  20.0 0.0 2:14.82
> > > ksoftirqd/2
> > >     42 root      20   0       0      0      0 S  20.0 0.0 2:08.67
> > > ksoftirqd/6
> > >      1 root      20   0  169644  10212   7796 S   0.0 0.1 0:01.52 
> > > systemd
> > >      2 root      20   0       0      0      0 S   0.0 0.0 0:00.00 
> > > kthreadd
> > >      3 root       0 -20       0      0      0 I   0.0 0.0 0:00.00 
> > > rcu_gp
> > >      4 root       0 -20       0      0      0 I   0.0 0.0 0:00.00
> > > rcu_par_gp
> > >      6 root       0 -20       0      0      0 I   0.0 0.0 0:00.00
> > > kworker/0:0H-kblockd
> > >      7 root      20   0       0      0      0 I   0.0 0.0 0:00.05
> > > kworker/u16:0-event+
> > >
> > > The stacks of the two kworker processes show the same output:
> > >
> > > [<0>] 0xffffffffffffffff
> > >
> > > I have appended the top 5000 lines tracing as a compressed ascii file
> > > out-cut.txt,gz and the dmesg output as compressed ascii file 
> > > dmesg.txt.gz.
> > >
> > > I hope, this helps to find out where the problem with the high CPU 
> > > load of
> > > the kworker processes come from.
> > Thanks this is very helpful.
> >
> > I suspect what you are seeing is an issue with the usb hubport present
> > before but now uncovered due to the upstream change e9fb08d617bf
> > ("xhci: prevent bus suspend if a roothub port detected a over-current
> > condition")[1], which was as well backported to v4.19.y in 4.19.119.
> >
> > Can you add some dynamic debugging on the 'drivers/usb/'[2] ideally at
> > boot time. On runtime it is
> >
> > # echo 'file drivers/usb/* +p;' > 
> > /sys/kernel/debug/dynamic_debug/control
> >
> > or as kernel parameter to have enable the debug messages at boot time
> > already:
> >
> > dyndbg="file drivers/usb/* +p;"
> >
> > Can you attach the dmesg with the enabled debugging?
> >
> > Regards,
> > Salvatore
> >
> >   [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9fb08d617bfae5471d902112667d0eeb9dee3c4
> >   [2] 
> > https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html