Solved BUG in sysctl?

Debugging some inconsistencies I was seeing in how x11/sfwbar plugin shows the CPU temperature I discovered this:
Code:
[11:08]fmc000@tu45b-freebsd ~> sysctl -n dev.cpu.0.temperature; sysctl -n -x dev.cpu.0.temperature
34.0C
0x00000bf5
[11:09]fmc000@tu45b-freebsd ~>
The problem I see is that BF5 in HEX is equivalent to 3061 in DEC, meaning 30.61°C . So it looks like that there is a conversion problem somwehere. Or am I missing something?
 
0xbf5 represents the temperature in deciKelvin. To convert it to Celsius, divide the value by 10 and subtract 273.15, which results in 32.95.
 
0xbf5 represents the temperature in deciKelvin. To convert it to Celsius, divide the value by 10 and subtract 273.15, which results in 32.95.
Thanks for your input but the result doesn't look good either (32.95 is not 34). Anyways I tweaked the sfwbar plugin acccording to your input, let's see how it goes.

Edit: looks good, I tried to stress my laptop and the reported temperature increased accordingly whilst before the change it was almost stuck to a (now I know) meaningless value. I guess I'll report a bug against x11/sfwbar.
 
If I'm reading /usr/src/sbin/sysctl/sysctl.c:show_var() correctly, your OID should be printed like this (in a very simplified form), resulting indeed in "33.0C":
C:
if (xflag)
        printf("%#010jx\n", temp);
else
        printf("%.1fC\n", (float) temp / 10.0 - 273.15);
Are you sure the value hasn't changed between the two calls (which is unlikely, but still)?
 
If I'm reading /usr/src/sbin/sysctl/sysctl.c:show_var() correctly, your MIB should be printed like this (in a very simplified form), resulting indeed in "33.0C":
C:
if (xflag)
        printf("%#010jx\n", temp);
else
        printf("%.1fC\n", (float) temp / 10.0 - 273.15);
Are you sure the value hasn't changed between the two calls (which is unlikely, but still)?
Of course I cannot be sure but honestly, as you look at my first post, I find it very unlikely. Anyways, you're obviously correct.
 
Of course I cannot be sure but honestly, as you look at my first post, I find it very unlikely.
I understand, I asked only because, in my case, everything looks correct:
Code:
$ OID=hw.acpi.thermal.tz0.temperature
$ for i in $(seq 2); do sysctl -nx $OID; sysctl -n $OID; done
0x00000c00
34.1C
0x00000c00
34.1C
 
As I am curious I have launched sysctl -n -x dev.cpu.0.temperature a few times. The output contains a subset of possible hex values. Actually it is 0x00000c4F, 0x00000c59, 0x00000c63, 0x00000c81 which corresponds to 42°C, 43°C, 44°C and 47°C. It seems to me that the sensor provides results in steps of 1°C which should be reasonable.
 
I understand, I asked only because, in my case, everything looks correct:
Code:
$ OID=hw.acpi.thermal.tz0.temperature
$ for i in $(seq 2); do sysctl -nx $OID; sysctl -n $OID; done
0x00000c00
34.1C
0x00000c00
34.1C
Long shot: this is a completely different sensor. My MB BIOS is trash and I had to completely disable the ACPI thermal capabilities. I need to use the kernel coretemp driver to get some meaningful results. With that said, I tried again, inspired by you:

Code:
[16:15]fmc000@tu45b-freebsd ~> for i in (seq 0 7)
                                   set OID dev.cpu.$i.temperature
                                   sysctl -nx $OID
                                   sysctl -n $OID
                               end
0x00000be1
33.0C
0x00000bf5
31.0C
0x00000be1
31.0C
0x00000be1
32.0C
0x00000bff
33.0C
0x00000bff
35.0C
0x00000be1
31.0C
0x00000be1
34.0C
[16:16]fmc000@tu45b-freebsd ~>

As you can see 0xBE1 can assume all values between 31 and 34 :D and 0xBF5 (33) is reported as 35. I guess it can be good enough to monitor a laptop but...
 
You compare the hex result of one measurement with the °C result of a next measurement. My assumption is that the accuracy of the temperature sensor including the analog-to-digital converter is +/- a few °C. That means that for a constant CPU temperature the read-out is not constant but with some jitter of +/- a few °C.

Unfortunately I did not manage to find an application note or such on Intels website. In practice +/- a few °C is good enough for the purpose of the sensor. It would be nice to know if there is some information available which can be retrieved without having to sign a non-disclosure agreement with Intel.
 
Long shot: this is a completely different sensor. My MB BIOS is trash and I had to completely disable the ACPI thermal capabilities. I need to use the kernel coretemp driver to get some meaningful results.
It doesn't matter. It is sysctl(8) who handles Kelvin-to-Celsius conversion, and if it's wrong, it would be wrong for all OIDs with the same type and format. Just to be sure, I loaded coretemp and got the same (i.e. correct) results:
Code:
$ OID=dev.cpu.0.temperature
$ for i in $(seq 2); do sysctl -nx $OID; sysctl -n $OID; done
0x00000bff
34.0C
0x00000bff
34.0C

set OID dev.cpu.$i.temperature
You got me wrong. I looped the same sysctl(8) invocations to catch potential temperature changes between different calls. Interestingly, as chrbr already pointed out, that seems to be what's happening in your case after all, not the conversion error.
 
As this thread pointed out there were no bugs in sysctl and it turned out that there were a couple of issues in x11/sfwbar that have been fixed upstream, so the next version should work fine on FreeBSD with regards to CPU temp monitorning.
 
Back
Top