As advised on this topic : I post a new topic about this issue, giving as much details as I can.
As many NUC7 users reported, (NUC7I3BNK for me) when I updated my BIOS from the factory one to a newest revision, the temperature reported on LINUX based systems is -263°C.
PLEASE be sure to note the following:
- The CPU temperature reported was the RIGHT one using the NUC with the factory firmware.
- It is now impossible to downgrade to factory firmware because of the security changes introduced with revision 0050 "Due to a security enhancement, it will not be possible to go to any BIOS earlier than BIOS 0050." Source : https://downloadmirror.intel.com/27397/eng/BN_0060_ReleaseNotes.pdf https://downloadmirror.intel.com/27397/eng/BN_0060_ReleaseNotes.pdf
- I dont know when this bug was introduced, but it happens at least since the 0052 revision,
- I have tried with 5 differents NUC7I3BNK, I ordered and assembled dozens in my company lately so I could try many NUC with many BIOS revisions, data was consistent, works on factory BIOS, doesnt work after "recent" revisions.
- I thought it might be a bug with new BIOS revisions, or maybe just the CPU sensor ID that got modified for some reason in new BIOS revisions and Linux systems are reading the wrong probe by default.
- I know that Linux is not officially supported (yet) by Intel for NUC's at least, but it might be an "easy" fix that would help many people, specially considering it was working well with old firmwares.
I would like to know if you could consider fixing it with the next revisions, even if I guess that you have some other major fixes to work on lately
Thanks a lot for your help Intel !
I upgraded a NUC7i7BNH to BIOS 52. From Windows, I do not see any issues with the sensor display. Now, this Windows software is directly accessing the shared memory of the eSIO device and displaying the sensor readings exposed there. I would presume that the Linux lm-sensors driver for this eSIO is doing the same thing. If not, well, this might explain what is going wrong.
N.Scott.Pearson Thanks for your answer, I totally get what you say, in this case we could think Linux doesnt read it "the proper way" like Windows does, but the point i'm trying to make is that it was working like a charm on Linux before those BIOS updates, Linux was reading it fine so something must have been changed in the NUC BIOS since then, I was just asking if this could be reverted in an update soon. This issue got mentionned in details so many times lately and we could think devs would know what has been changed since then so I guess it would be a doable fix?
If I go back to them with a vague report like this, it will go to the bottom of the list and likely never get addressed. Because it is working as designed on Windows (and has throughout these various BIOS releases) and because Linux is not formally supported, someone from the Linux world will have to determine what the BIOS is doing wrong.
N.Scott.Pearson Well with all due respect, if I have to be a Linux engineer to report an issue to Intel, especially when it's a known bug (nowhere near vague here : " "), what's the point of this place exactly? Without to mention that the dev would have no problem at all knowing when and what they modified sensor wise in earlier bios revisions...
Anyway thanks for your answer,
Ok, I am now at home (i.e. no more blind by-the-book, what-part-of-Linux-isn't-supported-didn't-you-understand? responses -- which I hate being the messenger for anyway) and am now able to see this other thread.
Here's the poop: As devices aimed at the Desktop PC market, there are absolutely zero requirements for the NUC BIOSs to support any part of the ACPI crap that is necessary for the implementation of passive cooling in Mobile (battery-restrictive) environments. For some unfathomable reason, the BIOS contains some (IMHO) totally unnecessary ACPI support - obviously broken ACPI support - for at least one thermal zone. I agree; this support either needs to be fixed or it needs to be ripped out entirely. I would (obviously) vote for the latter, but I am retired and they don't give me a vote anymore. I will pass on the complaint...
N.Scott.Pearson Ok, thanks a lot for your detailed answer and for passing on this issue.
I understand very well your position on this, and frankly, if it didnt work at all from the beginning on Linux I probably wouldnt even have reported this here, but when something works fine (in this case report the right temp) and suddenly it doesnt anymore, you could think that it's an "easy", or at least doable, fix / revert to do and that's why I decided to post about it.
Well, in this case there's an answer because I have seen this issue before.
In the general case, your thoughts are logical but dead wrong. The problem is that most issues like this, when introduced in the course of an update, are the result of side-effects or unexpected consequences. The fix that was being introduced is not something that you just rip out because of a (relatively speaking, insignificant) side-effect like this; that will almost never happen. No, the side-effect will need to be prioritized and, at the right time, investigated and repaired - and without affecting that other fix.
Then, the issue of Linux not being a supported OS environment comes into play. The BIOS team will not, under any circumstances, install Linux and debug an issue like this (they simply don't have the knowledge to do so nor the time that this will take). If the issue cannot be reproduced on Windows, then the Linux community must diagnose the issue far enough that the fix becomes obvious. If they can't, then it isn't going to get fixed, period. You may not like this stance, but it is what it is and it isn't likely to change (not when the Linux attach rate is less than 5% and the attach rate for any particular distribution of Linux is substantially less than 1%). Everyone seems to think that, because it is Intel, resources are cheap and available. This is NOT (never was and likely never will be) the case; the NUC team - like every team at Intel - has severely limited resources and these resources are going to be applied to the features and issues that represent the biggest ROI for the organization - and that is going to be on Windows.