Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #67658 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Salvatore Bonaccorso <carnil@debian.org> - 2020-08-02 15:50 +0200
    Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Salvatore Bonaccorso <carnil@debian.org> - 2020-08-02 18:30 +0200
      Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Salvatore Bonaccorso <carnil@debian.org> - 2020-08-11 21:30 +0200
        Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Dirk Kostrewa <dirk.kostrewa@mailbox.org> - 2020-08-12 13:10 +0200
          Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Dirk Kostrewa <dirk.kostrewa@mailbox.org> - 2020-08-12 18:00 +0200
            Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Salvatore Bonaccorso <carnil@debian.org> - 2020-08-12 18:10 +0200
              Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Dirk Kostrewa <dirk.kostrewa@mailbox.org> - 2020-08-13 11:00 +0200
              Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Dirk Kostrewa <dirk.kostrewa@mailbox.org> - 2020-08-21 11:40 +0200
            Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Salvatore Bonaccorso <carnil@debian.org> - 2020-08-28 16:40 +0200
              Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Salvatore Bonaccorso <carnil@debian.org> - 2020-08-29 11:40 +0200
                Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Dirk Kostrewa <dirk.kostrewa@mailbox.org> - 2020-09-04 18:00 +0200
                  Bug#966703: linux-image-4.19.0-10-amd64: kworker process with permanent high CPU load Salvatore Bonaccorso <carnil@debian.org> - 2020-09-04 19:20 +0200

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

Control: tags -1 + moreinfo

Hi Dirk

On Sun, Aug 02, 2020 at 10:00:27AM +0200, Dirk Kostrewa wrote:
> Package: src:linux
> Version: 4.19.132-1
> Severity: normal
> 
> Dear Maintainer,
> 
> after booting the kernel 4.19.0-10-amd64, there is a kworker process running
> with a permanent high CPU load of almost 90% as reported by the "top"
> command:
> 
> $ top
> top - 09:48:19 up 0 min,  4 users,  load average: 1.91, 0.58, 0.20
> Tasks: 218 total,   2 running, 216 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.8 us, 12.4 sy,  0.0 ni, 84.5 id,  0.0 wa,  0.0 hi,  2.3 si,  0.0
> st
> MiB Mem :  15889.4 total,  14173.1 free,    889.3 used,    827.0 buff/cache
> MiB Swap:      0.0 total,      0.0 free,      0.0 used.  14677.7 avail Mem
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
>    64 root      20   0       0      0      0 R  86.7   0.0 0:47.41
> kworker/0:2+pm
>     9 root      20   0       0      0      0 S  20.0   0.0 0:08.84
> ksoftirqd/0
>   364 root     -51   0       0      0      0 S   6.7   0.0 0:00.50
> irq/126-nvidia
>  1177 dirk      20   0 2921696 122848  94268 S   6.7   0.8 0:02.23 kwin_x11
>     1 root      20   0  169652  10280   7740 S   0.0   0.1 0:01.56 systemd
>     2 root      20   0       0      0      0 S   0.0   0.0 0:00.00 kthreadd
> ...
> 
> The expected result after booting the kernel 4.19.0-10-amd64 is a kworker
> process with a CPU load close to 0%.
> 
> As a control, booting the previous kernel 4.19.0-9-amd64 does not show a
> high CPU load for the kworker process. Instead, the kworker CPU load
> reported by the "top" command is 0.0%.
> 
> Therefore, I suspect a bug in the kernel 4.19.0-10-amd64.
> 
> Neither "dmesg" nor "journalctl -b" show any messages containing "kworker".
> 
> I am using Debian/GNU Linux 10.5 with kernel 4.19.0-10-amd64 and libc6:amd64
> 2.28-10.
> 
> If you need more information, I would be happy to provide it.

To find out what could be the cause, could you have a look at
https://www.kernel.org/doc/html/latest/core-api/workqueue.html#debugging
this could help determining isolating why the kworker goes crazy.

Regards,
Salvatore

[toc] | [next] | [standalone]

#67659

Hi Dirk,

On Sun, Aug 02, 2020 at 03:44:09PM +0200, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi Dirk
> 
> On Sun, Aug 02, 2020 at 10:00:27AM +0200, Dirk Kostrewa wrote:
> > Package: src:linux
> > Version: 4.19.132-1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > after booting the kernel 4.19.0-10-amd64, there is a kworker process running
> > with a permanent high CPU load of almost 90% as reported by the "top"
> > command:
> > 
> > $ top
> > top - 09:48:19 up 0 min,  4 users,  load average: 1.91, 0.58, 0.20
> > Tasks: 218 total,   2 running, 216 sleeping,   0 stopped,   0 zombie
> > %Cpu(s):  0.8 us, 12.4 sy,  0.0 ni, 84.5 id,  0.0 wa,  0.0 hi,  2.3 si,  0.0
> > st
> > MiB Mem :  15889.4 total,  14173.1 free,    889.3 used,    827.0 buff/cache
> > MiB Swap:      0.0 total,      0.0 free,      0.0 used.  14677.7 avail Mem
> > 
> >   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> >    64 root      20   0       0      0      0 R  86.7   0.0 0:47.41
> > kworker/0:2+pm
> >     9 root      20   0       0      0      0 S  20.0   0.0 0:08.84
> > ksoftirqd/0
> >   364 root     -51   0       0      0      0 S   6.7   0.0 0:00.50
> > irq/126-nvidia
> >  1177 dirk      20   0 2921696 122848  94268 S   6.7   0.8 0:02.23 kwin_x11
> >     1 root      20   0  169652  10280   7740 S   0.0   0.1 0:01.56 systemd
> >     2 root      20   0       0      0      0 S   0.0   0.0 0:00.00 kthreadd
> > ...
> > 
> > The expected result after booting the kernel 4.19.0-10-amd64 is a kworker
> > process with a CPU load close to 0%.
> > 
> > As a control, booting the previous kernel 4.19.0-9-amd64 does not show a
> > high CPU load for the kworker process. Instead, the kworker CPU load
> > reported by the "top" command is 0.0%.
> > 
> > Therefore, I suspect a bug in the kernel 4.19.0-10-amd64.
> > 
> > Neither "dmesg" nor "journalctl -b" show any messages containing "kworker".
> > 
> > I am using Debian/GNU Linux 10.5 with kernel 4.19.0-10-amd64 and libc6:amd64
> > 2.28-10.
> > 
> > If you need more information, I would be happy to provide it.
> 
> To find out what could be the cause, could you have a look at
> https://www.kernel.org/doc/html/latest/core-api/workqueue.html#debugging
> this could help determining isolating why the kworker goes crazy.

Please as well to the above one additional thing: Can you reproduce
the issue when the kernel does not get tained? So without loading the
propriertary, out-of-tree modules.

This is particularly important if the issue can be tracked down, found
in upstream and needs to be reported upstream.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#67747

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

[toc] | [prev] | [next] | [standalone]

#67758

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#67759

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

[toc] | [prev] | [next] | [standalone]

#67760

Hi,

Just commenting on the following:

On Wed, Aug 12, 2020 at 05:53:57PM +0200, Dirk Kostrewa wrote:
[...]
> 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 mentioned commit, is included in the following upstream versions
(relevant for Debian): v4.19.119 (so in buster), v5.6.8 (and so the
buster-backports kernel), v5.7-rc3.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#67763

Hi Salavatore,

I have kernel "linux-image-4.19.0-10-amd64/stable,now 4.19.132-1 amd64" 
installed, so it should already include the mentioned commit, if I 
understand correctly (I'm a bit confused by the two different version 
numbers used by Debian). I have also tried the most recent kernel 
"linux-image-5.6.0-0.bpo.2-amd64/buster-backports 5.6.14-2~bpo10+1 
amd64". For both kernels, I see the two kworker processes with high CPU 
load.

Regards,

Dirk.

Am 12.08.20 um 18:05 schrieb Salvatore Bonaccorso:
> Hi,
>
> Just commenting on the following:
>
> On Wed, Aug 12, 2020 at 05:53:57PM +0200, Dirk Kostrewa wrote:
> [...]
>> 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 mentioned commit, is included in the following upstream versions
> (relevant for Debian): v4.19.119 (so in buster), v5.6.8 (and so the
> buster-backports kernel), v5.7-rc3.
>
> Regards,
> Salvatore

[toc] | [prev] | [next] | [standalone]

#67816

Hi Salvatore,

I just want to inform you that I've installed the recent kernel from the 
Buster backports, 5.7.0-0.bpo.2-amd64 #1 SMP Debian 5.7.10-1~bpo10+1 
(2020-07-30) x86_64 GNU/Linux, and I'm still seeing the two kworker 
processes with high CPU load, probably related to the two USB ports with 
over-current condition.

Regards,

Dirk.

Am 12.08.20 um 18:05 schrieb Salvatore Bonaccorso:
> Hi,
>
> Just commenting on the following:
>
> On Wed, Aug 12, 2020 at 05:53:57PM +0200, Dirk Kostrewa wrote:
> [...]
>> 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 mentioned commit, is included in the following upstream versions
> (relevant for Debian): v4.19.119 (so in buster), v5.6.8 (and so the
> buster-backports kernel), v5.7-rc3.
>
> Regards,
> Salvatore

[toc] | [prev] | [next] | [standalone]

#67888

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#67904

Hi Dirk,

Thanks for testing that.

On Sat, Aug 29, 2020 at 11:04:43AM +0200, Dirk Kostrewa wrote:
> Hi Salvatore,
> 
> I have enabled the verbose debugging mode on the command line and have
> appended the first 5000 lines of the dmesg output to this e-mail, running
> the current kernel from the Buster backports with the two kworker processes
> with high CPU load present.
> 
> After that, I have applied your patch to this kernel and rebooted with the
> patched kernel:
> 
> 5.7.0-0.bpo.2-amd64 #1 SMP Debian 5.7.10-1~bpo10+1a~test (2020-08-28) x86_64
> GNU/Linux
> 
> With your patch applied, the two kworker processes with high CPU load
> completely disappeared!

Unfortunately I suspect this indicates either a HW fault or a HW
design error as stated in the found kernel-thread which was just
uncovered by the mentioned kernel fix (which we temporarily reverted
with the patch). I can try to ask Alan Stern.

There might be a workaround workarble for you, the issue should
disapear if you prevent the system to automatically try to suspend
usb2 root hub (but you have the same on usb1 root hub).

# echo on >/sys/bus/usb/devices/usb2/power/control

will do that for the usb2 root hub.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#67986

Hi Salvatore,

meanwhile, Dell has replaced the mainboard of my laptop, and after that, 
both the USB over-current kernel messages and the kworker processes with 
high CPU load are gone.

Many thanks for caring about my bug report!

Best regards,

Dirk.

Am 29.08.20 um 11:26 schrieb Salvatore Bonaccorso:
> Hi Dirk,
>
> Thanks for testing that.
>
> On Sat, Aug 29, 2020 at 11:04:43AM +0200, Dirk Kostrewa wrote:
>> Hi Salvatore,
>>
>> I have enabled the verbose debugging mode on the command line and have
>> appended the first 5000 lines of the dmesg output to this e-mail, running
>> the current kernel from the Buster backports with the two kworker processes
>> with high CPU load present.
>>
>> After that, I have applied your patch to this kernel and rebooted with the
>> patched kernel:
>>
>> 5.7.0-0.bpo.2-amd64 #1 SMP Debian 5.7.10-1~bpo10+1a~test (2020-08-28) x86_64
>> GNU/Linux
>>
>> With your patch applied, the two kworker processes with high CPU load
>> completely disappeared!
> Unfortunately I suspect this indicates either a HW fault or a HW
> design error as stated in the found kernel-thread which was just
> uncovered by the mentioned kernel fix (which we temporarily reverted
> with the patch). I can try to ask Alan Stern.
>
> There might be a workaround workarble for you, the issue should
> disapear if you prevent the system to automatically try to suspend
> usb2 root hub (but you have the same on usb1 root hub).
>
> # echo on >/sys/bus/usb/devices/usb2/power/control
>
> will do that for the usb2 root hub.
>
> Regards,
> Salvatore

[toc] | [prev] | [next] | [standalone]

#67987

Hi Dirk,

On Fri, Sep 04, 2020 at 05:51:58PM +0200, Dirk Kostrewa wrote:
> Hi Salvatore,
> 
> meanwhile, Dell has replaced the mainboard of my laptop, and after that,
> both the USB over-current kernel messages and the kworker processes with
> high CPU load are gone.
> 
> Many thanks for caring about my bug report!

Thanks for reporting back! So I'm closing as well the bugreport as
thre is nothing to be done on Linux side for it.

Glad if it was of help.

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web