K-worker problem on A20 based boards

Sigge · June 27, 2018

K-worker takes 10-20 % of one cpu core with later kernels.

Does the 4.17 kernel still have this problem? Or is bionic a solution?

vlad59 · June 27, 2018

This is due the a kernel change so the distribution shoud not change that at all.

You can use the search to find a palliative.

guidol · June 27, 2018

7 hours ago, Sigge said:

K-worker takes 10-20 % of one cpu core with later kernels.

Does the 4.17 kernel still have this problem? Or is bionic a solution?

Tasks:  92 total,   1 running,  56 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us,  4,5 sy,  0,0 ni, 95,5 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  1022520 total,   752444 free,    74228 used,   195848 buff/cache
KiB Swap:   131068 total,   131068 free,        0 used.   896112 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 8268 root      20   0       0      0      0 I   7,6  0,0   0:30.49 kworker/0:0

root@bpi-a20(192.168.6.3):~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU   PMIC   DC-IN  C.St.

20:24:04:  960MHz  0.19   5%   5%   0%   0%   0%   0% 35.9°C 39.3°C   4.62V  0/6
20:24:10:  960MHz  0.17   8%   8%   0%   0%   0%   0% 35.3°C 39.4°C   4.63V  0/6
20:24:15:  960MHz  0.16   7%   7%   0%   0%   0%   0% 35.5°C 39.4°C   4.50V  0/6
20:24:21:  960MHz  0.31   7%   7%   0%   0%   0%   0% 35.1°C 39.2°C   4.58V  0/6
20:24:26:  960MHz  0.26   7%   7%   0%   0%   0%   0% 35.6°C 39.3°C   4.57V  0/6

The kworker load seems to be very short (with 7-20%) while the complete cpu load is at 0.19?

Sigge · June 28, 2018

Hi, yes I have seen the remedy but it seems you loose thermal monitoring? Or you can use an older kernel. So I was wondering if the new kernel solves this. Seems like it is not?

vlad59 · June 28, 2018

I'm using the workaround for the last month but my Banana pi has not a lot of work to do (load average: 0,21, 0,15, 0,11) so I really don't know if there is a risk or not.

sgei · August 7, 2018

Hi,

yesterday I installed kernel 4.17.13 - problem is solved!

Steffen

Sigge · August 8, 2018

That´s great! Is the thermal sensors working?

I noticed that installing the nightly builds, I lost hdd temp. Do you have a hdd and do you see the temperature?

sgei · August 8, 2018

root@bpro:/etc/armbianmonitor/datasources# ll
insgesamt 0
lrwxrwxrwx 1 root root 27 Aug  8 12:03 pmictemp -> /sys/power/axp_pmu/pmu/temp
lrwxrwxrwx 1 root root 47 Aug  8 12:03 soctemp -> /sys/devices/virtual/thermal/thermal_zone0/temp
root@bpro:/etc/armbianmonitor/datasources# cat pmictemp
31700
root@bpro:/etc/armbianmonitor/datasources# cat soctemp
cat: soctemp: Das Argument ist ungültig

/usr/bin/armbianmonitor: Zeile 352: [: -ge: Einstelliger (unärer) Operator erwartet.
     °C 32.2°C   4.89V  0/6
18:11:45:  960MHz  0.43   8%   3%   4%   0%   0%   0%/usr/bin/armbianmonitor: Zeile 351: read: Lesefehler: 0: Das Argument ist ungültig

Steffen

Sigge · September 26, 2018

On 8/7/2018 at 1:41 PM, sgei said:

Hi,

yesterday I installed kernel 4.17.13 - problem is solved!

Steffen

How do I install 4.17.13?

sgei · January 2, 2019

Hello,

I know there are some threads regarding this issue, but there does not seem to be a correct solution.

Since kernel 4.14 (or maybe earlier), there are some Kworker processes that consume 10-25% CPU.

In May 2018 I once had an image built with the kernel 4.17.13. With this the problem had disappeared.
But now with the DEV-kernel 4.19.X it's back.

Can someone please investigate or say something about this?

Steffen

Edited January 2, 2019 by zador.blood.stained
Merged here and renamed the thread to a more generic name

vlad59 · January 2, 2019

It won't help a lot but every kernel I tried starting with 4.14 had this problem (I can't remember every single one).

Removing the module fixes it for me with no problems.

joximus · January 9, 2019

On 1/2/2019 at 9:39 PM, vlad59 said:

It won't help a lot but every kernel I tried starting with 4.14 had this problem (I can't remember every single one).

Removing the module fixes it for me with no problems.

What module?

sgei · January 9, 2019

Hi,

add

rmmod sun4i_gpadc

in

/etc/rc.local

But I do not understand why there is no real fix for this problem.

Steffen

disconnect · January 18, 2019

I've never had this problem, until i've updated to 4.19.13 kernel, with the update last sunday. Since that, 10% cpu in average eaten by kworker.

ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.19.13-sunxi

vlad59 · January 18, 2019

On 1/9/2019 at 2:49 PM, sgei said:

But I do not understand why there is no real fix for this problem.

There is a workaround and even when run at 100% CPU for several hours without any heatsink a Banana Pi does not heat that much and is very stable .... At least I'm not interested to spend time searching a fix for that

guidol · January 18, 2019

46 minutes ago, disconnect said:

I've never had this problem, until i've updated to 4.19.13 kernel, with the update last sunday. Since that, 10% cpu in average eaten by kworker.

for latest user-built armbian it looks like the same amount:

ARMBIAN 5.72 user-built Debian GNU/Linux 9 (stretch) 4.20.2-sunxi
Linux bpi-pihole 4.20.2-sunxi #5.72 SMP Fri Jan 18 18:15:55 +03 2019 armv7l GNU/Linux

top

Spoiler

root@bpi-pihole(192.168.6.3):~# top|grep kworker
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3165 root 20 0 0 0 0 I 9,9 0,0 0:18.45 kworker/1:1-eve
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3180 root 20 0 0 0 0 I 16,8 0,0 0:02.04 kworker/0:0-eve
3165 root 20 0 0 0 0 I 6,6 0,0 0:18.65 kworker/1:1-eve
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3165 root 20 0 0 0 0 I 9,8 0,0 0:18.95 kworker/1:1-mm_
3165 root 20 0 0 0 0 I 10,3 0,0 0:19.26 kworker/1:1-eve
3027 root 20 0 0 0 0 R 4,0 0,0 0:33.24 kworker/1:0+eve
3165 root 20 0 0 0 0 I 3,3 0,0 0:19.36 kworker/1:1-eve
167 root 0 -20 0 0 0 I 0,7 0,0 0:02.28 kworker/0:1H-kb
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3180 root 20 0 0 0 0 I 16,5 0,0 0:02.54 kworker/0:0-eve
3027 root 20 0 0 0 0 I 9,2 0,0 0:33.52 kworker/1:0-eve
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3165 root 20 0 0 0 0 I 6,6 0,0 0:19.56 kworker/1:1-mm_
3027 root 20 0 0 0 0 I 3,3 0,0 0:33.62 kworker/1:0-eve
166 root 0 -20 0 0 0 I 0,3 0,0 0:00.51 kworker/1:1H-kb
167 root 0 -20 0 0 0 I 0,3 0,0 0:02.29 kworker/0:1H-kb
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3165 root 20 0 0 0 0 I 9,9 0,0 0:19.86 kworker/1:1-eve
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3180 root 20 0 0 0 0 I 16,8 0,0 0:03.05 kworker/0:0-eve
3165 root 20 0 0 0 0 I 6,6 0,0 0:20.06 kworker/1:1-eve
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0
3165 root 20 0 0 0 0 I 9,9 0,0 0:20.36 kworker/1:1-eve
3165 root 20 0 0 0 0 R 8,9 0,0 0:20.63 kworker/1:1+eve
3165 root 20 0 0 0 0 I 7,6 0,0 0:20.86 kworker/1:1-eve
7 root 20 0 0 0 0 I 0,0 0,0 0:00.55 kworker/u4:0-ev
34 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 kworker/u5:0

armbianmonitor -m

Spoiler

root@bpi-pihole(192.168.6.3):~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St.

22:37:56: 960MHz 0.16 8% 7% 0% 0% 0% 0% 32.1°C 33.6°C 4.79V 0/6
22:38:02: 960MHz 0.23 14% 8% 0% 0% 4% 0% 32.0°C 33.3°C 4.79V 0/6
22:38:08: 960MHz 0.21 9% 9% 0% 0% 0% 0% 31.9°C 33.3°C 4.67V 0/6
22:38:14: 960MHz 0.19 7% 6% 0% 0% 0% 0% 31.8°C 33.5°C 4.80V 0/6
22:38:19: 960MHz 0.18 11% 10% 0% 0% 0% 0% 31.8°C 33.7°C 4.80V 0/6
22:38:24: 960MHz 0.16 7% 6% 0% 0% 0% 0% 31.7°C 33.5°C 4.76V 0/6
22:38:30: 960MHz 0.31 11% 11% 0% 0% 0% 0% 32.0°C 33.4°C 4.80V 0/6
22:38:35: 960MHz 0.26 7% 7% 0% 0% 0% 0% 31.9°C 33.4°C 4.77V 0/6
22:38:41: 960MHz 0.24 11% 10% 0% 0% 0% 0% 32.1°C 33.3°C 4.79V 0/6
22:38:47: 528MHz 0.22 7% 6% 0% 0% 0% 0% 32.0°C 33.4°C 4.79V 0/6
22:38:52: 960MHz 0.20 10% 10% 0% 0% 0% 0% 31.8°C 33.6°C 4.79V 0/6
22:38:58: 960MHz 0.19 7% 6% 0% 0% 0% 0% 31.8°C 33.4°C 4.79V 0/6
22:39:03: 960MHz 0.49 23% 14% 2% 0% 5% 0% 32.3°C 33.4°C 4.80V 0/6
22:39:09: 960MHz 0.45 7% 7% 0% 0% 0% 0% 32.1°C 33.5°C 4.78V 0/6
Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St.
22:39:15: 960MHz 0.50 11% 10% 0% 0% 0% 0% 31.7°C 33.4°C 4.79V 0/6
22:39:20: 528MHz 0.49 7% 6% 0% 0% 0% 0% 31.8°C 33.5°C 4.77V 0/6
22:39:26: 960MHz 0.53 11% 10% 0% 0% 0% 0% 32.2°C 33.3°C 4.77V 0/6
22:39:32: 528MHz 0.49 7% 7% 0% 0% 0% 0% 32.1°C 33.5°C 4.80V 0/6
22:39:38: 960MHz 0.45 11% 11% 0% 0% 0% 0% 32.0°C 33.2°C 4.79V 0/6
22:39:43: 528MHz 0.41 11% 11% 0% 0% 0% 0% 32.3°C 33.3°C 4.79V 0/6
22:39:49: 528MHz 0.38 7% 6% 0% 0% 0% 0% 32.0°C 33.3°C 4.79V 0/6
22:39:55: 528MHz 0.35 10% 10% 0% 0% 0% 0% 31.9°C 33.4°C 4.79V 0/6
22:40:00: 960MHz 0.68 12% 7% 0% 0% 4% 0% 31.8°C 33.5°C 4.72V 0/6
22:40:06: 960MHz 0.62 15% 13% 1% 0% 0% 0% 32.2°C 33.4°C 4.83V 0/6
22:40:12: 528MHz 0.57 6% 6% 0% 0% 0% 0% 31.6°C 33.3°C 4.80V 0/6
22:40:18: 960MHz 0.61 11% 10% 0% 0% 0% 0% 32.3°C 33.6°C 4.82V 0/6
22:40:23: 528MHz 0.56 7% 7% 0% 0% 0% 0% 32.0°C 33.6°C 4.79V 0/6
22:40:29: 960MHz 0.51 10% 10% 0% 0% 0% 0% 31.7°C 33.7°C 4.80V 0/6
22:40:35: 960MHz 0.47 7% 6% 0% 0% 0% 0% 31.9°C 33.7°C 4.80V 0/6
Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St.
22:40:40: 528MHz 0.47 11% 11% 0% 0% 0% 0% 31.8°C 33.5°C 4.79V 0/6
22:40:46: 960MHz 0.43 7% 6% 0% 0% 0% 0% 31.6°C 33.6°C 4.80V 0/6
22:40:51: 960MHz 0.40 12% 11% 0% 0% 0% 0% 32.0°C 33.6°C 4.79V 0/6
22:40:56: 960MHz 0.37 7% 6% 0% 0% 0% 0% 31.9°C 33.5°C 4.79V 0/6
22:41:02: 960MHz 0.50 17% 11% 0% 0% 4% 0% 32.0°C 33.7°C 4.83V 0/6
22:41:08: 960MHz 0.46 7% 6% 0% 0% 0% 0% 31.7°C 33.5°C 4.79V 0/6
22:41:13: 960MHz 0.42 10% 10% 0% 0% 0% 0% 31.9°C 33.6°C 4.78V 0/6
22:41:19: 528MHz 0.39 7% 7% 0% 0% 0% 0% 32.2°C 33.4°C 4.77V 0/6
22:41:25: 960MHz 0.40 11% 10% 0% 0% 0% 0% 31.7°C 33.4°C 4.78V 0/6
22:41:31: 528MHz 0.37 11% 11% 0% 0% 0% 0% 32.4°C 33.5°C 4.79V 0/6
22:41:36: 960MHz 0.34 6% 6% 0% 0% 0% 0% 32.0°C 33.5°C 4.79V 0/6
22:41:42: 528MHz 0.31 10% 10% 0% 0% 0% 0% 32.3°C 33.7°C 4.77V 0/6
22:41:48: 960MHz 0.29 7% 7% 0% 0% 0% 0% 31.8°C 33.5°C 4.79V 0/6
22:41:53: 960MHz 0.26 11% 11% 0% 0% 0% 0% 32.1°C 33.4°C 4.79V 0/6
22:41:59: 960MHz 0.24 6% 6% 0% 0% 0% 0% 31.8°C 33.5°C 4.83V 0/6
Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St.
22:42:04: 960MHz 0.38 17% 12% 0% 0% 3% 0% 32.3°C 33.7°C 4.79V 0/6
22:42:09: 960MHz 0.43 7% 6% 0% 0% 0% 0% 32.1°C 33.5°C 4.79V 0/6
22:42:15: 960MHz 0.40 11% 10% 0% 0% 0% 0% 32.2°C 33.4°C 4.79V 0/6
22:42:21: 960MHz 0.48 7% 6% 0% 0% 0% 0% 31.9°C 33.5°C 4.71V 0/6
22:42:26: 960MHz 0.44 11% 11% 0% 0% 0% 0% 31.9°C 33.6°C 4.80V 0/6
22:42:32: 960MHz 0.41 7% 6% 0% 0% 0% 0% 32.1°C 33.5°C 4.76V 0/6
22:42:37: 960MHz 0.62 10% 10% 0% 0% 0% 0% 31.9°C 33.7°C 4.76V 0/6
22:42:43: 960MHz 0.57 7% 6% 0% 0% 0% 0% 31.9°C 33.6°C 4.80V 0/6
22:42:48: 528MHz 0.52 12% 11% 0% 0% 0% 0% 31.8°C 33.7°C 4.80V 0/6
22:42:54: 960MHz 0.48 6% 6% 0% 0% 0% 0% 32.1°C 33.4°C 4.79V 0/6
22:42:59: 960MHz 0.52 11% 11% 0% 0% 0% 0% 31.8°C 33.5°C 4.77V 0/6
22:43:05: 960MHz 0.64 13% 8% 0% 0% 4% 0% 31.8°C 33.6°C 4.80V 0/6
22:43:10: 960MHz 0.67 11% 11% 0% 0% 0% 0% 32.1°C 33.3°C 4.77V 0/6
22:43:16: 960MHz 0.57 7% 6% 0% 0% 0% 0% 32.3°C 33.5°C 4.79V 0/6
22:43:21: 528MHz 0.52 11% 11% 0% 0% 0% 0% 32.1°C 33.5°C 4.79V 0/6
Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St.
22:43:27: 960MHz 0.48 7% 6% 0% 0% 0% 0% 32.0°C 33.4°C 4.79V 0/6
22:43:33: 960MHz 0.52 10% 10% 0% 0% 0% 0% 31.8°C 33.5°C 4.79V 0/6
22:43:38: 960MHz 0.48 7% 6% 0% 0% 0% 0% 31.7°C 33.4°C 4.80V 0/6
22:43:44: 960MHz 0.44 10% 10% 0% 0% 0% 0% 31.7°C 33.6°C 4.78V 0/6
22:43:49: 960MHz 0.49 7% 7% 0% 0% 0% 0% 31.6°C 33.5°C 4.80V 0/6
22:43:55: 960MHz 0.53 12% 11% 0% 0% 0% 0% 32.1°C 33.6°C 4.79V 0/6
22:44:00: 960MHz 0.56 12% 7% 0% 0% 4% 0% 32.1°C 33.5°C 4.76V 0/6
22:44:06: 960MHz 0.63 12% 11% 0% 0% 0% 0% 31.8°C 33.5°C 4.83V 0/6
22:44:11: 960MHz 0.58 7% 7% 0% 0% 0% 0% 31.9°C 33.3°C 4.70V 0/6
22:44:17: 960MHz 0.53 12% 11% 0% 0% 0% 0% 32.2°C 33.4°C 4.79V 0/6
22:44:22: 528MHz 0.49 7% 7% 0% 0% 0% 0% 32.3°C 33.4°C 4.80V 0/6
22:44:29: 960MHz 0.45 9% 9% 0% 0% 0% 0% 31.8°C 33.7°C 4.79V 0/6
22:44:34: 528MHz 0.41 11% 10% 0% 0% 0% 0% 31.8°C 33.4°C 4.79V 0/6
22:44:40: 960MHz 0.38 7% 6% 0% 0% 0% 0% 32.2°C 33.4°C 4.79V 0/6
22:44:46: 528MHz 0.55 10% 10% 0% 0% 0% 0% 31.6°C 33.5°C 4.71V 0/6
Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St.
22:44:51: 960MHz 0.50 7% 7% 0% 0% 0% 0% 31.8°C 33.5°C 4.79V 0/6
22:44:57: 960MHz 0.46 11% 11% 0% 0% 0% 0% 32.3°C 33.6°C 4.79V 0/6
22:45:02: 960MHz 0.43 13% 8% 0% 0% 3% 0% 32.0°C 33.5°C 4.79V 0/6
22:45:09: 960MHz 0.47 9% 9% 0% 0% 0% 0% 32.1°C 33.6°C 4.80V 0/6
22:45:14: 960MHz 0.43 7% 7% 0% 0% 0% 0% 31.8°C 33.5°C 4.79V 0/6
22:45:20: 960MHz 0.40 11% 11% 0% 0% 0% 0% 32.1°C 33.7°C 4.79V 0/6
22:45:25: 528MHz 0.41 7% 6% 0% 0% 0% 0% 32.1°C 33.6°C 4.79V 0/6
22:45:31: 960MHz 0.38 11% 11% 0% 0% 0% 0% 32.2°C 33.4°C 4.79V 0/6
22:45:37: 528MHz 0.35 7% 6% 0% 0% 0% 0% 32.0°C 33.6°C 4.77V 0/6

Madozu · March 7, 2019

Removing the module sun4i_gpadc from the kernel, helps somewhat on my A20 Cubietruck with latest user-built Armbian (5.76, Kernel 4.19.25-sunxi). The constant 5-7% CPU consumption of "kworker-eve" has disappeared, but every 10 seconds the CPU load is still up to 25% for one second (as it did before the module removal). Here's the "vmstat 1" output:

root@cubietruck:~# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 1888928   9680  87180    0    0    59     1   47   54  1  6 93  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   32   40  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   29   39  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   25   38  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   38   54  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   27   38  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0  157   42  0 25 75  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   40   53  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   44   56  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   27   40  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   27   35  0  0 100  0  0
 0  0      0 1888904   9680  87180    0    0     0     0   29   39  0  0 100  0  0

Is there anything I can do beside the removal of the sun4i_gpadc module?

gashtaan · April 13, 2019

Hi guys,

after I tried to downgrade kernel to 5.31 because of these problems, I bricked the system (unrecognized MMC card device), so I had to overwrite u-boot and /boot manually on mounted SD card to bring it to life. I don't know how exactly I did it, but now I have 4.19.20 kernel without these symptoms - no more excesive CPU usage by kworker, CPU temperature drops by more than 10 degrees.

The problem is that cpufreq is not working anymore:

no or unknown cpufreq driver is active on this CPU

Maybe there is some connection to it?

tbenr · May 19, 2019

hello guys,

i have similar problems,

after a couple of days (system load):

  ____      _     _      _                   _
 / ___|   _| |__ (_) ___| |_ _ __ _   _  ___| | __
| |  | | | | '_ \| |/ _ \ __| '__| | | |/ __| |/ /
| |__| |_| | |_) | |  __/ |_| |  | |_| | (__|   <
 \____\__,_|_.__/|_|\___|\__|_|   \__,_|\___|_|\_\


Welcome to ARMBIAN 5.73 stable Ubuntu 18.04.2 LTS 4.19.38-sunxi
System load:   440.90 440.88 440.73    Up time:       4 days
Memory usage:  33 % of 2010MB     IP:            192.168.0.5
CPU temp:      36°C
Usage of /:    18% of 9.8G

[349513.892856] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[349513.892899] rcu: 	1-...0: (1 GPs behind) idle=f7e/1/0x40000000 softirq=2073249/2073249 fqs=13470346
[349513.892904] rcu: 	(detected by 0, t=36887707 jiffies, g=4774253, q=1486233)
[349513.892928] Sending NMI from CPU 0 to CPUs 1:
[349576.912647] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[349576.912691] rcu: 	1-...0: (1 GPs behind) idle=f7e/1/0x40000000 softirq=2073249/2073249 fqs=13476101
[349576.912696] rcu: 	(detected by 0, t=36903462 jiffies, g=4774253, q=1486540)
[349576.912720] Sending NMI from CPU 0 to CPUs 1:

and system become unusable...

any known way to fix the issue?

Tido · May 19, 2019

27 minutes ago, tbenr said:

any known way to fix the issue?

armbianmonitor -u tells the reader all the details about your Installation, like Kernel-Version and much more

tbenr · May 19, 2019

http://ix.io/1Jvf

just updated to armbian 5.85 and blacklisted sun4i_gpadc module

i'll let you know if still in trouble

tbenr · May 20, 2019

no way, today i cannot even connect via ssh (timeout)

lampra · May 21, 2019

Not sure if it's the same issue but i can't also connect to cubietruck (after update to armbian 5.85) via ssh, webmin, apache, node-red. Though I can connect via ftp and wireguard works!! I am away now so logs will be available next Saturday.

tbenr · May 21, 2019

6 hours ago, lampra said:

Not sure if it's the same issue but i can't also connect to cubietruck (after update to armbian 5.85) via ssh, webmin, apache, node-red. Though I can connect via ftp and wireguard works!! I am away now so logs will be available next Saturday.

it is a different issue here, cubietruck becomes progressively unresponsive and after a couple of days the only way to interact is to power it off holding the physical button.

I'll try to use older kernels...

jeloneal · July 7, 2019

Is there any news on this kworker issue? Actually, I'm running armbian 5.90 with 4.19.57 kernel an the problem persists. Before, I was running dev-kernel 5.1 which didn't fix the issue either.

Bernie_O · July 27, 2019

On 6/28/2018 at 2:32 PM, Sigge said:

I have seen the remedy but it seems you loose thermal monitoring?

I switched to Kernel 4.19.57 on my Banana Pi M1 and can confirm that kworker eats 15-20% cpu constantly. Could get rid of it with:

modprobe -r sun4i_gpadc sun4i_gpadc_iio

With that I also lost thermal monitoring. However I found another source for thermal measurement calculated with: ( (in_temp_raw + in_temp_offset) / 10 ):

/sys/bus/iio/devices/iio:device0/in_temp_raw
/sys/bus/iio/devices/iio:device0/in_temp_offset
/sys/bus/iio/devices/iio:device0/in_temp_scale

While the scale seems to be wrong (it is only 10, not 100), it is a quite similar measurement like the one which only works with the 2 gpadc modules enabled:

/sys/devices/virtual/thermal/thermal_zone0/temp

However, I have absolutely no idea where this temperature comes from. Does anyone know where that measurement comes from? Could it be used as an alternative to the thermal monitoring with the gpadc modules?

Edited July 27, 2019 by Bernie_O
Added calculation example

gashtaan · July 29, 2019

On 7/27/2019 at 2:20 PM, Bernie_O said:

However, I have absolutely no idea where this temperature comes from. Does anyone know where that measurement comes from? Could it be used as an alternative to the thermal monitoring with the gpadc modules?

I suppose, it's the temperature from PMIC, armbian monitor show this temperature too.

If you remove /etc/armbianmonitor/datasources/soctemp file, it will show PMIC temperature in MOTD as CPU temperature, but in my case this temperature is quite different than the one from GPADC module.

jeloneal · July 7, 2020

I found this one recently: https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi

Maybe it helps? I will have to test this in the long run.

Igor · July 7, 2020

1 hour ago, jeloneal said:

Maybe it helps? I will have to test this in the long run.

It helps and its already solved. https://docs.armbian.com/Release_Changelog/
https://armbian.atlassian.net/browse/AR-305

jeloneal · July 8, 2020

15 hours ago, Igor said:

It helps and its already solved. https://docs.armbian.com/Release_Changelog/
https://armbian.atlassian.net/browse/AR-305

Thank you!

Sign In

K-worker problem on A20 based boards

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Similar Content

Important Information