[BUG] btop 1.3.x no longer shows per-cpu utilization/temp in CPU pane

[msenizai]

Read the README.md and search for similar issues before posting a bug report!

Any bug that can be solved by just reading the prerequisites section of the README will likely be ignored.

Describe the bug

Upgrading to RHEL 9.3. Installing btop from EPEL9 repo. On any system running this the per-cpu graphics aren't being displayed. The chart to the left works as expected, and at top the overall system CPU utilization and temp show up, but not any of the cores.

To Reproduce

Install btop via dnf from EPEL repo.

[Steps to reproduce the behavior:]

Expected behavior

Launch btop, see individual CPU core utilization and temps.

Info (please complete the following information):

• btop++ version: btop --version
  v1.3.0, v1.3.2
• Binary:
  ldd /usr/bin/btop
  linux-vdso.so.1 (0x0000800000170000)
  libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00001555552e5000)
  libm.so.6 => /lib64/libm.so.6 (0x000015555520a000)
  libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00001555551ef000)
  libc.so.6 => /lib64/libc.so.6 (0x0000155554fe6000)
  /lib64/ld-linux-x86-64.so.2 (0x000015555551e000)
• Architecture: [x86_64, aarch64, etc.] x86_64
• Platform: [Linux, FreeBSD, OsX] Linux RHEL9.3
• (Linux) Kernel: 5.14.0-362.8.1.el9_3.x86_64
• (OSX/FreeBSD) Os release version:
• Terminal used: /bin/bash
• Font used: LANG=en_US.UTF-8

Additional context

Contents of ~/.config/btop/btop.log
2024/03/06 (11:08:40) | ===> btop++ v.1.3.2
2024/03/06 (11:08:40) | DEBUG: Running in DEBUG mode!
2024/03/06 (11:08:40) | INFO: Logger set to DEBUG
2024/03/06 (11:08:40) | DEBUG: Using locale en_US.UTF-8
2024/03/06 (11:08:40) | INFO: Running on /dev/pts/0
2024/03/06 (11:08:40) | INFO: Failed to load libnvidia-ml.so, NVIDIA GPUs will not be detected: libnvidia-ml.so.1: cannot open shared object file: No such file or directory
2024/03/06 (11:08:40) | INFO: Failed to load librocm_smi64.so, AMD GPUs will not be detected: librocm_smi64.so.6: cannot open shared object file: No such file or directory
2024/03/06 (11:08:40) | DEBUG: Shared::init() : Initialized.
2024/03/06 (11:08:49) | INFO: Quitting! Runtime: 00:00:09

[saShenka-dev]

This seems to only affect Intel CPUs from what I have seen

[msenizai]

This is affecting both Intel and AMD systems in my lab.

[saShenka-dev]

Resizing the window seems to make the per-cpu utilization visible again

[msenizai]

I tested that just now on a couple systems. No change in display. Just incase it was an SSH terminal setting I logged in via the iKVM and the per-cpu metric in the top-right pane still is empty.

[dreadedhamish]

Here is what Im observing (2CPU's 40 cores total):
On startup - default 80px wide - no individual CPU info
Extend window to about 128px - individual CPU info appears
Shrink window down below 128px to 80px- individual CPU info remains visible.
So it looks like a draw error to me.

Also I'm ony seeing temp on core 1 and 2 - from memory it used to diaplay for every core.

[ElderMedic]

This happened to me as well, I need to press number key 234 to disable all other hardware panels to enable per core info and put 234 back on. We are using an AMD EPYC cpu with 64 cores.

[q5sys]

This happened to me as well, I need to press number key 234 to disable all other hardware panels to enable per core info and put 234 back on. We are using an AMD EPYC cpu with 64 cores.

This is exactly what I'm running into with my Dual Epyc 7B13 sytstem. Even on a 4K monitor I have to turn everything else off and seriously decrease the font size to be able to see the CPU info, otherwise its just a single line of blocks

[mogoreanu]

Can confirm btop version 1.3.0, dual socket 72 threads the CPU pane stopped showing per-CPU load at the same window size as before.
Resizing window makes the pane show up and removing other panes (234) and adding them back helps too.
The change in behavior was confusing, spent some time looking through settings expecting that accidental button clicks with btop activated changed the behavior.

[q5sys]

On high core systems, it would be helpful if there was a way to control the size of the CPU boxes. I Looked through the btop.cpp file but it wasn't immediately apparent to me how the box sizes are calculated, so I could adjust it locally and recompile for my system.
I'm using btop to monitor an AI system, and I don't need the process list taking up 1/3rd of the screen, I'd rather sacrifice some of that area so I could get better monitoring of the rest of my hardware. If net was the same size as the memory panel, and the proc list could scale to the height of the mem/net box, The CPU chart would be able to show every thread. With the CPU boxes current size, it only shows ~ 1/2 of the threads.
Alternatively the GPU boxes don't need to have as much space, they could have their height limited to the number of text lines on the right hand side.
Image attached because it might be easier to explain what I'm seeing.

[Ray-Eldath]

I just found that neither decreasing the font nor enlarging the screen is needed. press 2 3 4 to hide other panels so that the cpu panel will take the whole screen, at this time the per-cpu utilization&temp should be rendered correctly, then press 2 3 4 again to bring everything back. the per-cpu info is still there.

tl;dr press 2 3 4, then 2 3 4 again.

would you mind try this workaround to see if it works? it works on my machine. @msenizai @saShenka-dev

[msenizai]

That works for me on some of my systems, but not all. They have identical OS images (stateless provisioning with Warewulf) so I don't know what could cause the difference.

[aristocratos]

@msenizai
Should be fixed as of commit 3f384c0

[DiabloRex]

None of the above works for me on dual core epyc 9754. I compared the new version with v1.2.13, and commented out line 817: "if (cmp_less(core_graphs.size(), n+1)) break;". Compiled again, and problem solved. @aristocratos

[zhengxiongli08]

None of the above works for me on dual core epyc 9754. I compared the new version with v1.2.13, and commented out line 817: "if (cmp_less(core_graphs.size(), n+1)) break;". Compiled again, and problem solved. @aristocratos

Works for me. Thank you.

[aristocratos]

Fixed in 4210f5f

[aristocratos]

Fixes included in release v1.4.0