-
-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3.1.0 CPU Temperature Display Regression #806
Comments
Could you provide the output of |
Right, I forgot to mention that I was unable to reproduce the issue with my Zen 2 Renoir APU as well. :^) |
@Derppening thank you! If you look at your own |
I am not sure what you mean. I thought this section is the temperature of the processor cores:
Does htop not use the |
You have one temp per chiplet (Tccd1/2), one temp for the die (Tdie) and one I can't guess off the top of my head (Tctl). Makes four. You have 12 CPU cores (24 with hyperthreading), so htop would like to see 12 or 24 temperatures (plus one for the die average but that's optional). And |
My understanding is that It would be nice if there is a way to determine the topology and assign each of |
This is broken in 3.0.x as well. I get this on 3.0.5-7 off Debian:
And on b7248f6:
So, unrolled, 3.0.5-7 lists the temperature for CPUs 1-3,9-11,13-15,21-23 (total 12, half of them), and b7248f6 for 1-3,9-11 (total 6, a quarter (conspicuously similar to half of the first package? but the CPU distribution is wrong)). This system is in a 2x6x2 configuration (two sockets, E5645 in each, HT on), lscpu says:
These are oddly non-continuous and match the populated output ranges (0-2,8-10), at least where one is populated at all. |
Okay, had access to an Zen3 system today. Here's some information I collected. Linux 5.4.0-100/proc/cpuinfo
sensors -u
Linux 5.13.0-35 (HWE)/proc/cpuinfo
sensors -u && sensors -j
uname -a
For further details feel free to ask … |
So the tl;dr from @BenBE's info here is that a Zen3 system, even with kernel 5.13, does not expose the core temperatures in a way that libsensors is able to read them. |
I don't think that is true. The Zen3 system @BenBE had access to is a 5800H, which is a Zen 3 APU. However, the Zen 3 APU temperature reporting in In addition, I think 5800H APUs uses 8-core CCDs, and since 5800H only has 8 cores, it might mean that only The following are /proc/cpuinfo
sensors -u && sensors -j
uname -a
|
Hm? Your |
If you are referring to the temperatures of the individual cores, then yeah, it seems that the I still think that, if possible, |
This is with an
And
|
I've just updated my OS to Ubuntu 22.04 LTS, and now my core temps are gone - i'd like them back, to state the obvious.
Observation: it worked fine on 21.04 Hirsute Hippo, also htop 3.0.5 Where should i file this bug next? lm-sensors/libsensors5? How do we drive this issue forward, so it gets resolved in a timely manner? #HaveANiceDay :3 EDIT: my box is an AMD Ryzen 5800X on B550 (ASUS TUF Gaming B550-Plus) - nct6775, i guess - that's what The nct6775 kernel mod is loaded, and it doesn't even tell me voltages anymore - so, is the lm-sensors code to blame? |
Most likely Your kernel logs should show the following:
You may try to upgrade to a newer kernel (5.17 is the first kernel version which implements reading from ASUS's own motherboard sensors without using Either way, the voltage issue does not appear to be related to the CPU temperature issue. The CPU temperature issue seems to stem from the fact that:
This algorithm would work on most Intel processors (it does on my i9-9900K), since each core has its own core temperature. However, for AMD CPUs, where temperatures are exposed on a per-CCX level, the new algorithm does not handle this, and so it defaults to the current display of displaying the CCX temperature as the core temperature.
I have suggested in an earlier reply that maybe htop can determine the topology of AMD CPUs (i.e. which cores belong to which CCX) using some way (whatever Optimally, this issue should be fixed in the kernel (if Windows can read the temperature of each core, what's stopping Linux from doing so?). Unfortunately, I don't know enough to start tinkering with that, and I don't know any efforts to rectify this as of this moment. EDIT: I guess another way could be just to blacklist AMD CPUs from using the new temperature detection algorithm, and revert to an older working version? |
I have a 5700X and was experiencing this issue myself using zenpower - I "fixed"(worked-around) it by putting
into an appropriate For clarity, my
|
Closes htop-dev#806. Closes htop-dev#1048. Closes htop-dev#1176. Closes htop-dev#1335. Addresses htop-dev#879 (on Linux).
Closes htop-dev#806. Closes htop-dev#1048. Closes htop-dev#1176. Closes htop-dev#1335. Addresses htop-dev#879 (on Linux).
Closes htop-dev#806. Closes htop-dev#1048. Closes htop-dev#1176. Closes htop-dev#1335. Addresses htop-dev#879 (on Linux).
After upgrading from htop 3.0.5 to 3.1.0, htop displays temperatures for only 3 cores, and marks the temperature of other cores as
N/A
. When cross-referencing with the output fromsensors
, it appears that htop may have been treatingTdie
,Tccd1
andTccd2
as three cores.For reference, the following screenshot is taken using
htop 3.1.0
on a Ryzen 9 5900X system.I also ran a
git bisect
and got the following:The text was updated successfully, but these errors were encountered: