Bug: wrong cpu temperature reading from inxi -Fxxxrza

[h2-1]

SwampRabbit, I've slowly come to realize that when I post stuff [as above] where I'm figuring out what inxi would have to do to allow roughly what the user is saying they are having an issue with, what I often, too often, lol, actually end up doing is creating the design specs for the new feature, which then usually results in my doing it, if it's not too hard and is quite certain to not break existing outputs for users. So those long posts are actually me trying to figure out how it could be done, if it can be done in a reasonable time. If you look on the inxi github issues, you'll see a bunch of things where I never was able to figure out a way to do x or y, but I left the stuff up as notes in case I, or someone else, ever was able or willing to try.

In this case, I think I'd faintly realized that the sensors data was this type of failure to update the actual logic and data structures, not just translate the old bash/gawk ones, but I'd never really acted on it or given it any real thought until last night.

Thanks for your nice comments too, that's always appreciated.

[SwampRabbit]

SwampRabbit, I've slowly come to realize that when I post stuff [as above] where I'm figuring out what inxi would have to do to allow roughly what the user is saying they are having an issue with, what I often, too often, lol, actually end up doing is creating the design specs for the new feature, which then usually results in my doing it, if it's not too hard and is quite certain to not break existing outputs for users. So those long posts are actually me trying to figure out how it could be done, if it can be done in a reasonable time. If you look on the inxi github issues, you'll see a bunch of things where I never was able to figure out a way to do x or y, but I left the stuff up as notes in case I, or someone else, ever was able or willing to try.

In this case, I think I'd faintly realized that the sensors data was this type of failure to update the actual logic and data structures, not just translate the old bash/gawk ones, but I'd never really acted on it or given it any real thought until last night.

Thanks for your nice comments too, that's always appreciated.

That's how it goes sometimes though.

I am glad if the comments can help boost morale, hopefully the donation can help keep the lights on the website or get you a few beers/coffees/whatever.

[cinclus]

___

[Stevo]

[cinclus]

___

[h2-1]

You'll make some progress here if you stop thinking this is a bug, it's not a bug, it's intended behavior, following tested rules. So your surprise that one system shows the 'same' data is hardly surprising, these choices result in roughly 95% [possibly much more, could be up to 98-99%] of systems showing the desired values, the choices weren't random. Since inxi could not, same as any other monitoring tool, 'know' which sensor data to prefer, in one case, the heavily tested inxi default test priorities resulted in undesired sensor data, and in the other, more normal case, inxi showed desired sensor data. This is expected and normal behavior, there is no bug involved here, there is just the fact that one of your systems happens to fall into the minority of systems where the default priorities for sensors does not show what you wanted to see, it's known that inxi can never hit 100% of all systems because that is impossible.

the new options allow you to modify how you want pinxi to use sensor arrays, how those options are used is up to the end user, not inxi, it will just follow what you tell it.

A bug is something that is unexpected, wrong according to the desired internal code logic, this is the opposite of a bug, it's designed behavior, intentional, and in the vast majority of cases, it delivers quite good results. It doesn't matter if you have to think of this as a bug, it isn't a bug, it's a feature. It's very rare that I get to use that classic expression, not a bug, but a feature, but this is certainly one of those times, lol.

Aside from all this, I actually believe that in your case, inxi is right, and your tools are wrong, that's because coretemp often reports a far higher temp than CPU/temp1 temps do, in many cases anyway. So if that's the case, in this instance, inxi is actually right, and your belief about what the temps should show are wrong. I can't say this for sure, but I lean towards that interpretation of your data, that is, I believe inxi is right to ignore your core temp values, and right to show your temp1 value. What other temperature monitoring tools show depends simply on what they have been told to show, that's it, period.

Best way to determine this is to reboot, go to bios, check board/cpu temps there, write them down, then look at sensors and see which temps are closest to those values. Coretemp if I remember right is a sensor that is located physically ON the actual cpu chip, whereas the other sensors tend to show the temp at the surface of the processor, which is what actually matters. So while I'm not in the mood to debate this, it's my considered opinion that there is not even a wrong display of temperature here, it's just a thing you believe should be showing which is not actually showing. Definitely NOT a bug, 100% certain.

[cinclus]

___

[richb]

Moderator comment

@ cinclus

Images in posts are limited to 640x 620. I have edited your post removing the image tags.

[h2-1]

While there can be cases where the output was misleading, which was my initial assumption before looking at it, in fact, I do not believe it is misleading in this case, or it quite unlikely to be so. If you read up on what the different sensors actually do, where they are physically located on the processor/board itself, this may or may not start to resonate.

In other words, while one can, and now pinxi can as well, select which sensors you prefer output from, in this case, it is my general view that actually inxi did pick the right sensors to use, though those may not have been the sensors you wanted to see.

There's nothing insulting in that, it's all strictly empirical. As I suggested, you can determine this for yourself by rebooting, entering bios, checking the cpu temp listed, but do it fast before it has time to really change, then note that, and compare it to the sensors you see from sensors.

There is no bug here, as I said. Nor does there even appear to be a user/developer issue in any real sense, that is, there is neither an internal code type bug or logic error, nor is there an external output selection error, everything that was supposed to happen, did happen, which means, all that testing done on the sensors feature is still solid and reliable relatively speaking.

And now there is a new option to use/remove specific sensors as well in pinxi, the choice to do that or not do it is of course up to the user. I don't know where MX gets its inxi from, but that will be in inxi 3.1.06 whenever that is released, maybe in a few weeks, not super pressing since this is just a kind of arcane new feature that nobody really asked for but which did solve this niche corner case issue in a subset of user cases, very few however.

[seaken64]

You use offensive language: I will not make 'progress' in the direction you want to explain.

I'm going to guess that English is not your first language. I didn't notice anything "offensive" - something rude or insulting.

I think you are trying to say you disagree with the developers statements.

For me, I am very impressed that the developer has paid such special attention to your query. I'm sure you'll find a solution if you are amenable and amiable, aka ameniable.

Seaken64