0

For some reason, my "top" command is showing wrong cpu load average. Like 100% cpu usage everytime, but, in fact, the cpu is 100% idle.

It's a Raspberry 3, running Fedora 28. CPU temperature is below 46C, so, the CPU is really idle. No hardware changed in last months.

Any idea why?

top - 21:47:52 up  1:02,  1 user,  load average: 4.00, 4.00, 4.00
Tasks: 139 total,   1 running,  84 sleeping,   0 stopped,   1 zombie
%Cpu0  :  0.5 us,  0.5 sy,  0.0 ni, 95.0 id,  0.0 wa,  4.0 hi,  0.0 si,  0.0 
%Cpu1  :  0.0 us,  0.5 sy,  0.0 ni, 99.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   996680 total,   210940 free,   294880 used,   490860 buff/cache
KiB Swap:   249852 total,   249852 free,        0 used.   680308 avail Mem

The CPU is idle, but the load average is wrong:

load average: 4.00, 4.00, 4.00

Using iotstat:

[root@raspberry ~]# iostat
Linux 5.0.5-100.fc28.armv7hl (raspberry)        04/08/2019      _armv7l_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.16    0.11    1.21    0.12    0.00   98.40
Improve this question
3
  • You top shows about 99% idle. You can't deduce idle from CPU temperature.
    – RalfFriedl
    Commented Apr 8, 2019 at 5:25
  • Yes, but see the counters: load average: 4.00, 4.00, 4.00
    – Arvy
    Commented Apr 8, 2019 at 12:11
  • If your point is the load average, then you should edit the question and say so.
    – RalfFriedl
    Commented Apr 8, 2019 at 16:55

2 Answers 2

Reset to default
2

There appears to be a bug in the vhciq driver in the 5.0.x kernel:

https://github.com/raspberrypi/linux/issues/2881

Reverting back to a 4.x kernel appears to solve this problem. I rolled back to the following with no issues:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1231413

Improve this answer
2
  • Yes, my kernel is 5.0.5-100.fc28.armv7hl. Probably you're right.
    – Arvy
    Commented Apr 9, 2019 at 12:47
  • You're right! My kernel was updated saturday, and I rebooted sunday, when the problem started: Removed: kernel.armv7hl 4.20.15-100.fc28 kernel-core.armv7hl 4.20.15-100.fc28 kernel-modules.armv7hl 4.20.15-100.fc28 Installed: kernel.armv7hl 5.0.5-100.fc28 kernel-core.armv7hl 5.0.5-100.fc28 kernel-modules.armv7hl 5.0.5-100.fc28
    – Arvy
    Commented Apr 9, 2019 at 12:50
1

kernel-5.0.9-200.fc29.armv7hl appears to have resolved this issue.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.