And again I ask why you think inxi is meant to monitor CPU temperatures while doing something like building a kernel, when much better tools are available.
Sure, you can cross the USA under your own power on a tall bike, unicycle, or even a pogo stick, but you're only seeking attention when there are touring bikes already made for this exact purpose (this is a standard answer from bike touring forum).
Bug: wrong cpu temperature reading from inxi -Fxxxrza
Re: Bug: wrong cpu temperature reading from inxi -Fxxxrza
I just wanted to do one follow up on this. While the actual original posting is not really an issue as far as I can tell, it's just a belief about what should show, roughly, in the process of starting to make inxi/pinxi able to do more granular sensor chip identification for --sensors-use and --sensors-exclude, I accidentally happened to have the best coincidence, for just now, with kernels 5.7, 5.8, there's a new set of sensor features which can offer a lot more sensors data in certain systems, like ryzen, but also others, and more types of device sensor data.
Had I not done this relatively quick hack fix to try to deal with this specific issue at least in theory, inxi would not internally have been able to handle these coming changes, it's still only part way there, but the latest version, today's pinxi, is far more able than ever before to deal with very advanced, and granular, sensor data, for disks, nvme drives, gpu sensors, networking sensors, etc.
Determining what a sensor 'is' may eventually require a significant refactoring of the sensor logic so that it will 'know' what each sensor belongs to, but that refactoring doesn't have to happen now, just the framework for it needs to be in place.
So this turned out to be a very fortunate thread for me to have dropped into.
I would however caution against the belief that coretemp are desirable in general, the reason inxi puts those last for cpu temp detection is that the coretemp sensors are located I believe inside the actual cpu core, and don't really reflect the external cpu temperature. This is not always the case, but it is often the case. What you usually, or what inxi usually, wants to see is the temp on the more external part of the cpu, the part closest to the heatsink/cooling stuff, so you can know what the termerature is at that point, in other words, how effective your cooling is. It's not uncommon to see coretemp at 10, maybe more, C higher than CPU or temp1 type temp numbers, because of where the actual sensor chip is located.
I've had to dip a bit into the true arcana, largely undocumented, of sensor chips to try to get a working sense of this stuff, it's a challenge to put it mildly, and the linux kernel is in process of introducing some pretty advanced sensor features for some system, other systems, of course, being subject to NDA issues, will remain very badly supported, but the overall direction of the linux kernel sensors group is very promising. As always, hats off to them, they have a BRUTAL task, made worse by NDAs that put them in a difficult situation of knowing the answer but being unable to use it... but still they struggle on, year after year.
So I'm glad this thread appeared, it is leading to some very positive results already in inxi internally, and already with some sensors data on some systems you will start to see some changes.
Had I not done this relatively quick hack fix to try to deal with this specific issue at least in theory, inxi would not internally have been able to handle these coming changes, it's still only part way there, but the latest version, today's pinxi, is far more able than ever before to deal with very advanced, and granular, sensor data, for disks, nvme drives, gpu sensors, networking sensors, etc.
Determining what a sensor 'is' may eventually require a significant refactoring of the sensor logic so that it will 'know' what each sensor belongs to, but that refactoring doesn't have to happen now, just the framework for it needs to be in place.
So this turned out to be a very fortunate thread for me to have dropped into.
I would however caution against the belief that coretemp are desirable in general, the reason inxi puts those last for cpu temp detection is that the coretemp sensors are located I believe inside the actual cpu core, and don't really reflect the external cpu temperature. This is not always the case, but it is often the case. What you usually, or what inxi usually, wants to see is the temp on the more external part of the cpu, the part closest to the heatsink/cooling stuff, so you can know what the termerature is at that point, in other words, how effective your cooling is. It's not uncommon to see coretemp at 10, maybe more, C higher than CPU or temp1 type temp numbers, because of where the actual sensor chip is located.
I've had to dip a bit into the true arcana, largely undocumented, of sensor chips to try to get a working sense of this stuff, it's a challenge to put it mildly, and the linux kernel is in process of introducing some pretty advanced sensor features for some system, other systems, of course, being subject to NDA issues, will remain very badly supported, but the overall direction of the linux kernel sensors group is very promising. As always, hats off to them, they have a BRUTAL task, made worse by NDAs that put them in a difficult situation of knowing the answer but being unable to use it... but still they struggle on, year after year.
So I'm glad this thread appeared, it is leading to some very positive results already in inxi internally, and already with some sensors data on some systems you will start to see some changes.
Re: Bug: wrong cpu temperature reading from inxi -Fxxxrza
Don't we want to keep coretemp below the critical temperatures, anyway?