repository Updated htop

[Igor]

• added support for boards that export temperature elsewhere (for example meson64-next/dev)

[lxde-OSIREN]

apt-get install lm-sensors

 

shows core temperatures, but the new htop shows temperatures now?

[guidol]

23 minutes ago, ftp-bin2fex said:

but the new htop shows temperatures now?

yes it does

The following packages will be upgraded:
  htop
Need to get 75.8 kB of archives.
Get:1 https://apt.armbian.com stretch/main arm64 htop arm64 2.1.2-3 [75.8 kB]
Fetched 75.8 kB in 1s (56.4 kB/s)
Unpacking htop (2.1.2-3) over (2.1.1-3) ...

 

[lxde-OSIREN]

that's good, I setup up custom watercooling for poweredge 1950 harpertown cpu and I had setup an app to check lm-sensors from android, would always be 49 degrees, so the server never made noise again but sometimes it would get pretty hot and shutdown, even blew off the water on the mobo and the end. Specific core temperatures would be even better for htop.

[Petee]

Very nice works great!

 

 

[Igor]

Fixed on Buster and Disco with apt update / upgrade.

[_r9]

That's really an open minded extension for htop. Fast and simple!

I've recognized an issue with temperature on my clearfog pro with Debian buster and stretch.

Clearfog Base (Debian Buster) works

htop version buster: 2.2.0-3~armbian5.92+1



bpi-m64 (Debian Buster) works

htop version buster: 2.2.0-3~armbian5.92+12.1.2-3

 

bpi-m2+ (Debian Stretch) works

htop version stretch: 2.1.2-3

 

 

Clearfog pro (Debian Buster and Stretch) doesn't work on a stretch and a buster installation
htop version buster: 2.2.0-3~armbian5.92+1
htop version stretch: 2.1.2-3

[Igor]

3 hours ago, _r9 said:

doesn't work on a stretch and a buster installation

This probably related to the fact that temp values are not on the (standard) locations where htop searches for values. A workaround could be implemented or fix htop ... once  

[guidol]

maybe symbolic-links as workaround?

[guidol]

2 hours ago, guidol said:

maybe symbolic-links as workaround?

some time ago I had this on a NanoPi K1 Plus:
 

temperature for armbian-monitor and welcome-screen (NPi K1 Plus stable):
cd  /etc/armbianmonitor/datasources/
ln -s /sys/devices/virtual/thermal/thermal_zone0/temp soctemp
ln -s /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp


Missing temp in armbianmonitor:

find /sys/devices/ -name temp                                       
/sys/devices/virtual/thermal/thermal_zone0/temp
/sys/devices/virtual/thermal/thermal_zone1/temp

Switch zone0 to zone1 for soctemp:
rm /etc/armbianmonitor/datasources/soctemp
ln -s /sys/devices/virtual/thermal/thermal_zone1/temp /etc/armbianmonitor/datasources/soctemp

===================================================================================
cd  /etc/armbianmonitor/datasources/
ln -s /sys/devices/virtual/thermal/thermal_zone0/temp soctemp

ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /etc/armbianmonitor/datasources/soctemp

/usr/lib/file
ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp


My
ln -s /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp

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

echo 'nameserver 192.168.6.3' >> /etc/resolv.conf
echo 200000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp


/usr/lib/armbian/armbian-hardware-monitor

# SoC temp: check sun7i legacy exception first, then standard path(s)
        if [[ -f /sys/class/hwmon/hwmon0/temp1_input ]]; then
                # usual convention with modern kernels
                ln -fs /sys/class/hwmon/hwmon0/temp1_input /etc/armbianmonitor/datasources/soctemp
        fi
===================================================================================

 

[@lex]

The path is hard coded in the HTOP for the cpu temp.

I think the problem is that some boards (kernel) use the hwmon driver and sometimes different kernel config.

I think the best approach would be to traverse /sys and try to find the label for the cputemp / gputemp / regulators, etc..

But what exactly look for to be Universal?

 

In my x64 for example, same Intel, different kernel configs (server vs desktop) points to different locations:

 

cat /sys/devices/platform/coretemp.0/hwmon/hwmon1/temp2_label 
Core 0
cat /sys/devices/platform/coretemp.0/hwmon/hwmon1/temp3_label 
Core 1

cat /sys/devices/platform/coretemp.0/hwmon/hwmon2/temp2_label 
Core 0

 

[_r9]

Hey guys,

 

thanks for helping me out and sorry for the late response.

 

I checked the thermal_zone as @guidoldescriped

 

cat /sys/devices/virtual/thermal/thermal_zone0/temp
84164

I also checked the link inside _/etc/armbianmonitor/datasources_
 

ls -l
total 0
lrwxrwxrwx 1 root root 47 Aug 28 10:40 soctemp -> /sys/devices/virtual/thermal/thermal_zone0/temp

It's all the same on the Clearfog pro as it is on the Clearfog base

@lex I cannot find a value like *temp[0-9]_label* But maybe this output can help
 

find /sys/devices/ |grep temp[0-9]
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_max_alarm
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_crit
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_input
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_max_alarm
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_crit
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_input
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_max_alarm
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_crit
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_input
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_max_alarm
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_crit
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_input
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_max_alarm
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_crit
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_input
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_max_alarm
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_crit
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_input
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_max_alarm
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_crit
/sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_input
/sys/devices/virtual/thermal/thermal_zone0/hwmon1/temp1_input

@Igor I have also noticed that the *CpuFreq[1-9]: ... MHz* section is missing in the htop frontend too, on all of my _Clearfog Pro_ devices

When I open up the /usr/bin/htop it looks like that there you can see the hardcoded files
 

u: ^@^@^@show processes of a single user^@      H: ^@^@^@hide/show user process threads^@^@      K: ^@^@^@hide/show kernel threads^@^@^@^@      F: ^@^@^@cursor follows process^@^@ F6 + -: ^@^@^@expand/collapse tree^@^@^@^@  P M T: ^@^@^@sort by CPU%, MEM% or TIME^@^@      I: ^@^@^@invert sort order^@^@^@ F6 > .: ^@^@^@select sort column^@^@Environment of process %d - %s^@^@Could not read process environment.^@Refresh^@"^@^@^@/sys/class/thermal/thermal_zone0/temp^@^@^@/sys/devices/virtual/thermal/thermal_zone0/temp^@/sys/class/hwmon/hwmon0/temp1_input^@/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_cur_freq^@^@/sys/devices/platform/soc/7081400.i2c/i2c-0/0-0036/regulator/regulator.1/microvolts^@/sys/devices/platform/soc/1f02400.i2c/i2c-4/4-0065/regulator/regulator.5/microvolts^@/sys/devices/platform/ff3c0000.i2c/i2c-0/0-001b/regulator/regulator.12/microvolts^@^@^@/sys/devices/platform/ff3c0000.i2c/i2c-0/0-0040/regulator/regulator.9/microvolts^@^@^@^@/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq^@^@/proc/uptime^@^@^@^@%64lf^@^@^@/proc/loadavg^@^@^@%32lf %32lf %32lf %32d/%32d %32d^@^@^@^@/proc/sys/kernel/pid_max^@^@^@^@/proc/%d/environ^@^@^@^@ 0 Cancel^@^@^@ 1 SI

 

The following files are available
 

cat /sys/devices/virtual/thermal/thermal_zone0/temp
66548
cat /sys/class/hwmon/hwmon0/temp1_input
62000
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory
cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq
cat: /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq: No such file or directory

 

This is all exactly the same on my Clearfog Base. But now I can see that on the Clearfog Base the CpuFreq is 0 Mhz. So the issue changed to

Clearfog Base:  Shows 0 MHz because the hardcoded files are missing

Clerafog Pro: Doesn't show that sections at all. It looks like this htop doesn't have this features at all

 

Aaaaaahhhhhh!!!!

Ok inside htop on the Clearfog Pro's I had to configure the Frequency and Temperature.

Solution

Enter htop
Press F2

 

 

Another Update

 

On my Clearfog Pro does the file **/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq** exist and its content switches between 800 and 1600 this is shown in htop
On the Clearfog Base is the whole directory **/sys/devices/system/cpu/cpufreq/** empty

[@lex]

Please check if you have:

 

cat /sys/class/hwmon/hwmon0/name

 

[_r9]

@lex yes this file exists on both devices with following content

cat /sys/class/hwmon/hwmon0/name
f1072004mdiomii00

 

[@lex]

According to this: https://github.com/armbian/build/blob/master/packages/bsp/helios4/90-helios4-hwmon.rules ,  it is not related to CPU temp.

My guess is just a missing kernel config.

 

[Beurett]

Hi, I'm Nanopi M4 user with Armbian Buster 5.95 and kernel 4.4.190-rk3399.

I found some weird behavior that put label which indicates big.LITTLE wrongly to each core. please refer this: https://forum.armbian.com/topic/11698-nanopi-m4-htop-recognizes-all-cores-as-little-cores

 

 

Installed htop version is: 2.2.0-3~armbian5.92+1 arm64.

[guidol]

Strange (for me)
I got one NanoPi Neo2 LTS (1GB) and 2 NanoPi Neo2 non-LTS (512MB) and alle three got the same dev-armbian:
 

non-LTS:
Debian Buster with Armbian Linux 5.3.7-sunxi64
package bsp-kernel[5.98.191027] u-boot[5.90] dtb[5.98.191027] firmware[5.98] config[5.98]
armbian branch    [dev]

LTS:
Debian Buster with Armbian Linux 5.3.7-sunxi64
package bsp-kernel[5.98.191027] u-boot[5.98] dtb[5.98.191027] firmware[5.98] config[5.98]
armbian branch    [dev]

but on the LTS Neo2 htop does show temperature and CPU-Speeds and on the 2 non-LTS it doesnt show it
The armbian on the LTS Neo2 was complied fresh yesterday and the armbian on the 2 non-LTS is updated via apt update/upgrade.

On all three armbianmonitor and the login does show the temperature.

 

Quote

This probably related to the fact that temp values are not on the (standard) locations where htop searches for values. A workaround could be implemented or fix htop ... once  

@Igor where can I read about /check the (standard) locations? I want to see whats missing on the non-LTS Neo2.

 

htop version is on all three devices 2.2.0-3~armbian5.92+1 arm64

[Igor]

5 minutes ago, guidol said:

it doesnt show

 

It shows values 0 or nothing at all? If this is the case, then htop user configuration is either wrong, missing has wrong permissions ... htop config is inside your home directory, .system/htop/something ...

[guidol]

11 minutes ago, Igor said:

 

It shows values 0 or nothing at all? If this is the case, then htop user configuration is either wrong, missing has wrong permissions ... htop config is inside your home directory, .system/htop/something ...

 Many Thanks!
htop didnt show anything on the non-LTS Neo2 = upgraded armbian.
I copied the content of the ~/.config/htop/htoprc from the working to the non-working Neo2 and now htop does show temperature and cpu-speeds also on the other system

 

non-working htoprc:
 

Spoiler

# Beware! This file is rewritten by htop when settings are changed in the interface.
# The parser is also very primitive, and not human-friendly.
fields=0 48 17 18 38 39 40 2 46 47 49 1
sort_key=40
sort_direction=1
hide_threads=0
hide_kernel_threads=1
hide_userland_threads=0
shadow_other_users=0
show_thread_names=0
show_program_path=1
highlight_base_name=0
highlight_megabytes=1
highlight_threads=1
tree_view=0
header_margin=1
detailed_cpu_time=0
cpu_count_from_zero=0
update_process_names=0
account_guest_in_cpu_meter=0
color_scheme=0
delay=15
left_meters=AllCPUs Memory Swap
left_meter_modes=1 1 1
right_meters=Tasks LoadAverage Uptime
right_meter_modes=2 2 2
 

 

working htoprc:

Spoiler

# Beware! This file is rewritten by htop when settings are changed in the interface.
# The parser is also very primitive, and not human-friendly.
fields=0 48 17 18 38 39 40 2 46 47 49 1
sort_key=46
sort_direction=1
hide_threads=0
hide_kernel_threads=1
hide_userland_threads=0
shadow_other_users=0
show_thread_names=0
show_program_path=1
highlight_base_name=0
highlight_megabytes=1
highlight_threads=1
tree_view=0
header_margin=1
detailed_cpu_time=0
cpu_count_from_zero=0
update_process_names=0
account_guest_in_cpu_meter=0
color_scheme=0
delay=15
left_meters=AllCPUs Memory Swap CpuTemp
left_meter_modes=1 1 1 2
right_meters=Hostname Tasks LoadAverage Uptime CpuFreq(1) CpuFreq(2) CpuFreq(3) CpuFreq(4)
right_meter_modes=2 2 2 2 2 2 2 2
 

 

[schwar3kat]

Thanks @Guidol,  I had the same issue with Orange Pi Zero Plus. 

One showed Cpu Temp And Cpu Frequency.  Two did not show the options.

~/.config/htop/htoprc was blank on the two that did not work.
Changing settings on htop did not populate the file and settings were lost between sessions.

File permissions were the same for all three.
I copied the working htoprc to the other two and this solved the problem.

[guidol]

5 minutes ago, Elektrický said:

~/.config/htop/htoprc was blank on the two that did not work.
File permissions were the same for all three.

I also had on all 3 Neo2 the same file-permissions:
 

ls -l ~/.config/htop/htoprc
-rw-r--r-- 1 root root 738 Okt 28 10:29 /root/.config/htop/htoprc

and only on my non-root user guido there was a htop-directory, but no htoprc - maybe because I didnt started htop as guido in the past