Nanopi M4: HTop recognizes all cores as little cores

[Beurett]

Hello,

I'm using Nanopi M4 installed Armbian Buster.
It works like charm but I found a strange behavior of the system.
In htop all cores are displayed as little core. but when I checked actual clocks in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq big cores are doing well (up to 1.8GHz).

 

htop result:

 

lscpu results:

Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              6
On-line CPU(s) list: 0-5
Thread(s) per core:  1
Core(s) per socket:  3
Socket(s):           2
Vendor ID:           ARM
Model:               4
Model name:          Cortex-A53
Stepping:            r0p4
CPU max MHz:         1800.0000
CPU min MHz:         408.0000
BogoMIPS:            48.00
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32

CPU SOCKET CORE ONLINE MAXMHZ    MINMHZ
0   0      0    yes    1416.0000 408.0000
1   0      1    yes    1416.0000 408.0000
2   0      2    yes    1416.0000 408.0000
3   0      3    yes    1416.0000 408.0000
4   1      4    yes    1800.0000 408.0000
5   1      5    yes    1800.0000 408.0000

Is this result normal?

[NicoD]

Hi.
What version of Armbian are you running?

Also please give the result of sudo armbianmonitor -a

I'm using Armbian 5.90 Bionic on the M4, and for me it's noted right in HTop. CPU 5&6 are big.
It could be a bug in HTop, or somewhere else. I don't think this hinders functionality. You could run a 7zip benchmark to see if it performs normal.
You should get a score like this with Buster.
 

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,6 CPUs LE)

LE
CPU Freq:  1735  1793  1795  1796  1792  1797  1797  1796  1797

RAM size:    1926 MB,  # CPU hardware threads:   6
RAM usage:   1323 MB,  # Benchmark threads:      6

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       4590   491    910   4466  |      94490   533   1513   8058
23:       4320   491    897   4402  |      92071   532   1497   7967
24:       4389   533    885   4719  |      89315   530   1479   7839
25:       4115   532    883   4699  |      86785   531   1455   7723
----------------------------------  | ------------------------------
Avr:             512    894   4571  |              531   1486   7897
Tot:             522   1190   6234

 

[GeorgeP]

I have a NanoPi Neo4 running "Debian Buster with Armbian Linux 4.4.190-rk3399" and I don't see this problem.

 

I see this in htop:

 

 

 

[Beurett]

2 hours ago, NicoD said:

Hi.
What version of Armbian are you running?

Also please give the result of sudo armbianmonitor -a

I'm using Armbian 5.90 Bionic on the M4, and for me it's noted right in HTop. CPU 5&6 are big.
It could be a bug in HTop, or somewhere else. I don't think this hinders functionality. You could run a 7zip benchmark to see if it performs normal.
You should get a score like this with Buster.

 

 

using Armbian 5.95 Buster with kernel 4.4.190-rk3399.

I cannot find -a option for armbianmonitor.. but when I run 7zip benchmark with -z option, the result is similar to yours. It seems the cpu performance is ok.

 

Do you have any idea what problem caused this?

[NicoD]

1 hour ago, Beurett said:

Do you have any idea what problem caused this?

No idea. I'll see if I can recreate this with Buster 5.95.
I don't think it's a problem in the meaning of "problem". Just a small bug in either htop or Buster.
I rarely use htop. So others will know more about that.

[coolchip]

Have the same issue with my XU4.

 

I have a workaround for this. Remove all files in /home/[username]/.config/htop and replace it with the files from /root/.config/htop. 

Then all cores are labeled with "big." and ".LITTLE" as usual. But as soon as you change the configuration (for example toggle "Tree" with F5), everything is broken again.

 

[coolchip]

A deeper inspection shows, that it has something to do with the file /home/[username]/.config/htop/htoprc.

The config parameter "right_meters" is set incorrectly.

 

For my XU4 the proper params are:

right_meters=Hostname Tasks LoadAverage Uptime CpuFreq(1) CpuFreq(2) CpuFreq(3) CpuFreq(4) CpuFreq(5) CpuFreq(6) CpuFreq(7) CpuFreq(8)

 

HTOP shows the wrong labels when the params are:

right_meters=Hostname Tasks LoadAverage Uptime CpuFreq CpuFreq CpuFreq CpuFreq CpuFreq CpuFreq CpuFreq CpuFreq

[Beurett]

37 minutes ago, NicoD said:

No idea. I'll see if I can recreate this with Buster 5.95.
I don't think it's a problem in the meaning of "problem". Just a small bug in either htop or Buster.
I rarely use htop. So others will know more about that.

 

Agree with you. I'll see the htop source code. Thanks!

 

2 minutes ago, coolchip said:

A deeper inspection shows, that it has something to do with the file /home/[username]/.config/htop/htoprc.

The config parameter "right_meters" is set incorrectly.

 

You're right. my htoprc file is same as yours. when I delete and recreate the file it works properly. It might be bug in Armbian customized htop.

[@lex]

Try this:

hit F2, select each label on the Right column and delete all CpuFreq (meter). Then add the available meters again. Exit htop and check again.

There is a meter called CpuFreq and CpuFreq1,CpuFreq2,... (cpu count). I think the correct meters should be CpuFreq1,2,3...8 and not CpuFreq.