Temperature Widget

jimp

FYI- coretemp and amdtemp are in the builds now. I'm not sure if there is a reliable way to detect support and auto-load the modules, if anyone has an idea, I'm open to suggestions. (And no, loading both all the time is not an option :-)

rcfa

@jimp:

FYI- coretemp and amdtemp are in the builds now. I'm not sure if there is a reliable way to detect support and auto-load the modules, if anyone has an idea, I'm open to suggestions. (And no, loading both all the time is not an option :-)

How about settings in the Advanced Setup Misc. tab that will add/remove the proper line to the boot config file?

jimp

Well manual setting is always an option, but automatic would be even better…

:-)

Otherwise, yes, a setting above/below powerd to select it would be possible. It would really be just about the same as the new code for crypto module I just committed.

wallabybob

@jimp:

FYI- coretemp and amdtemp are in the builds now. I'm not sure if there is a reliable way to detect support and auto-load the modules, if anyone has an idea, I'm open to suggestions. (And no, loading both all the time is not an option :-)

Various invocations of the CPUID instruction return a string identifying the CPU vendor, CPU features and instruction set options implemented. All this is reported in startup output though not in a concise form for easy parsing. On Linux the file /proc/cpuinfo reports this information in a cleanly structured way. Perhaps the FreeBSD proc filesystem does something similar.

Alternatively, I expect a few hours trolling through the appropriate Intel Architecture Reference Manual (and maybe the equivalent AMD document) and a bit of C nous would result in a program to issue shell commands to load the appropriate kernel modules on systems with the appropriate features.

jimp

You cat get the features from /var/run/dmesg.boot, assuming it actually shows up there.

If it does, it should be easy.

wallabybob

@jimp:

You cat get the features from /var/run/dmesg.boot, assuming it actually shows up there.

/var/log/dmesg.boot on my system.

On my system:

[2.1-BETA0][admin@pfsense2.test.example.org]/root(2): more /var/log/dmesg.boot
Copyright 1992-2012 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.3-RELEASE-p2 #1: Sun Jun 10 18:19:17 EDT 2012
root@FreeBSD_8.3_pfSense_2.1.snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: VIA Samuel 2 (797.74-MHz 686-class CPU)
Origin = "CentaurHauls" Id = 0x673 Family = 6 Model = 7 Stepping = 3
Features=0x803035

On more modern CPUs there will be more Features lines.

The string value of Origin will be "GenuineIntel" (case may be different) on Intel CPUs and "AuthenticAMD" (case may be different) on AMD CPUs.

Perhaps you could post the equivalent lines from a system with AES so I can check the reported features and the kernel code and Architecture manual to see the feature names for AES instructions and CPU core thermometer.

jimp

Well if you want to get fancy… (thought there doesn't seem to be an equivalent in php...)

https://github.com/freebsd/freebsd-head/blob/master/sys/dev/coretemp/coretemp.c#L118

mr_bobo

The temp widget doesn't show on my Dell pfSense box with a 2.66GHz P4 and I'm under the impression you can't get a Dell Dimension to show CPU temp due to hardware limitations.

My desktop is a Dell 4600 with a 2.8GHz P4 running FreeBSD 9.0 and I've installed every port available for it and ran every command I could come up with in an attempt to get it to show CPU temp to no avail.

My laptop is a Sony Vaio running the same OS and GKrellM has the option to show the temp for it's CPU's but the same option isn't available on the Dell.

As for some of the high temperatures mentioned, my Gateway laptop with a 1.2GHz Celeron running FreeBSD 7.4 would exit and shut down as a safety feature if it reached 105C. My Sony usually stays at or under 50C.

wallabybob

The startup should show a Features2 line containing the string "AESNI" if the CPU has the AES-NI instruction set - load the AES crypto module if AESNI is in the Features2 line (if present).

The string TM2 in the same Features2 line indicates presence of Thermal Monitor 2 described in the Intel Ref document:

An additional automatic thermal protection mechanism, called Thermal Monitor 2
(TM2), was introduced in the Intel Pentium M processor and also incorporated in
newer models of the Pentium 4 processor family. Intel Core Duo and Solo processors,
and Intel Core 2 Duo processor family all support TM1 and TM2. TM2 controls the
core temperature of the processor by reducing the operating frequency and voltage
of the processor and offers a higher performance level for a given level of power
reduction than TM1.

I suspect that testing TM2 might be a more accurate test than that used in https://github.com/freebsd/freebsd-head/blob/master/sys/dev/coretemp/coretemp.c#L118 which uses CPU family as an indicator of presence of TM2.

TM2 is probably Intel specific - I haven't checked AMD documentation.

stephenw10

The coretemp module will not run on a Pentium-M or P4 which does have TM2.
That would not work for us but is that because of the limitation in coretemp you mentioned? Could it work on the Pentium-M?

Steve

Edit: I could be reading this wrong but it looks to me as if the coretemp module looks at the cpuid registers returned by the CPU to check for the presence of on die thermal sensors.
cpuid 0x06 EAX bit 0 = "Digital temperature sensor supported"

Any Intel CPU that returns a 1 would be valid. Seems like a good test.

Edit: Except for the PIII which returns a 1 falsely!

wallabybob

@stephenw10:

Edit: Except for the PIII which returns a 1 falsely!

The maximum value of EAX on a CPUID instruction on a Pentium III is 3, hence returned values from CPUID when EAX=6 is "reserved". (The architecture manual says if EAX is greater than the maximum value supported by the CPU family then the value returned is that returned when EAX contains its max allowed value (in this case 3). When EAX is 3 in CPUID instruction the value returned in EAX is "Reserved".

@stephenw10:

Edit: I could be reading this wrong but it looks to me as if the coretemp module looks at the cpuid registers returned by the CPU to check for the presence of on die thermal sensors.
cpuid 0x06 EAX bit 0 = "Digital temperature sensor supported"

Any Intel CPU that returns a 1 would be valid. Seems like a good test.

Yes, but this test is done after verifying cpu_high is at least 6. cpu_high is set in i386/i386/identcpu.c to the highest valid value of EAX in CPUID instruction.

My impression from selected reading of the IA32 architecture documents some years ago is that the thermal management facility has significant cpu family specifics. The coretemp man page is quite clear that it supports the core CPUs and newer. Maybe there is no harm in loading coretemp on an unsupported CPU - maybe the worst it will do is report an error.

jimp

Yes, loading coretemp would be practically a no-op on an unsupported system. As when it's in the kernel, it simply does not attach if the hardware is not present. However, it will consume some memory just for having been loaded. Not a ton, but when every bit counts, loading it unnecessarily should be avoided.

Perhaps a manual option is best. Manual is best for the crypto module since in some cases you may not want it (if it's buggy with your cipher/workload, or you have some other chip/card you want to use…)

stephenw10

The only reason I mentioned the PIII is:

@https://github.com/freebsd/freebsd-head/blob/master/sys/dev/coretemp/coretemp.c#L166:

/*

Some CPUs, namely the PIII, don't have thermal sensors, but

report them when the CPUID check is performed in

coretemp_identify(). This leads to a later GPF when the sensor

is queried via a MSR, so we stop here.
*/
if (cpu_model < 0xe)
return (ENXIO);

If we used code similar to coretemp_identify the percentage of systems where coretemp was loaded incorrectly would be very small I would think.

Steve

Edit: Too ambiguous.

wallabybob

@stephenw10:

If we used code similar to coretemp_identify the percentage of systems where coretemp was loaded incorrectly would be very small I would think.eadily have

Duplicated logic can quickly become a maintenance pain: who wants to track coretemp.c for changes in CPUs it supports, especially when that logic is not in one neat area.

Based on Jimp's post
@jimp:

Yes, loading coretemp would be practically a no-op on an unsupported system. As when it's in the kernel, it simply does not attach if the hardware is not present. However, it will consume some memory just for having been loaded. Not a ton, but when every bit counts, loading it unnecessarily should be avoided.

I would suggest to anyone who cares:
1. Check if loadable device drivers which report an error in their probe or attach functions get unloaded automatically.
2a. If so, the "ongoing" cost of always loading coretemp on Intel CPUs would be quite small.
2b. If not, check for the coretemp sysctl(s) and if not there, kldunload coretemp to recover most (all?) the memory used by coretemp.

rcfa

Whenever you figure out which way to proceed, and implement that in a specific snapshot, would you please be so kind as to let us know what we should/must do with the manually installed coretemp.ko and boot config lines at that point?
I'd hate to have strange behavior or errors because the manual config clashes with what's done automatically..

jimp

If you put them in /boot/kernel/ then you don't have to do anything.

Loading it with loader.conf would still be fine, it can't load twice so even if it was auto loaded it would be a no-op.

Not really a wrong way to do it I'd say. I'm still leaning toward making it manual, it seems more in line with how we handle other such dilemmas.

rcfa

@jimp:

If you put them in /boot/kernel/ then you don't have to do anything.

Good.

@jimp:

Loading it with loader.conf would still be fine, it can't load twice so even if it was auto loaded it would be a no-op.

Not really a wrong way to do it I'd say. I'm still leaning toward making it manual, it seems more in line with how we handle other such dilemmas.

I wouldn't mind if we just had a check box in the appropriate place in the advanced setup pages, maybe with a pop-up list of choices what to use (coretemp, amdtemp, ACPI, etc.). Autodetection just screams like a lot of code maintenance in an open system where buggy BIOS, a variety of CPUs, etc. clash.

jimp

ACPI will always work no matter what.

I'm thinking a drop down just like the crypto choice will do:

None
coretemp (Intel Core* CPUs)
amdtemp (AMD CPUs)

Would be nice to have some more accurate descriptive text to put there, have to come up with something to explain that it may not work, etc, etc.

rcfa

@jimp:

ACPI will always work no matter what.

I'm thinking a drop down just like the crypto choice will do:

None
coretemp (Intel Core* CPUs)
amdtemp (AMD CPUs)

Would be nice to have some more accurate descriptive text to put there, have to come up with something to explain that it may not work, etc, etc.

Yup, that's what I was thinking about, like the crypto thing.
Couldn't instead of the None label be ACPI used? The idea ACPI would be a fall-back option, but if a CPU internal method is chosen, that's given preference if selected.

m4f1050

I am stuck with using mbmon, on my functions.inc.php I added one last check and copied mbmon to /usr/local/bin folder


function get_temp() {
//      switch(get_hwtype()) {
//              default:
//                      return;
//      }
//
//      return $ret;

         $temp_out = "";
         exec("/sbin/sysctl dev.cpu.0.temperature | /usr/bin/awk '{ print $2 }'
| /usr/bin/cut -d 'C' -f 1", $dfout);
         $temp_out = trim($dfout[0]);
         if ($temp_out == "") {
           exec("/sbin/sysctl hw.acpi.thermal.tz0.temperature | /usr/bin/awk '{
print $2 }' | /usr/bin/cut -d 'C' -f 1", $dfout);
           $temp_out = trim($dfout[0]);
         }
         if ($temp_out == "") {
           exec("/usr/local/bin/mbmon -T1 -i -c1", $dfout);
           $temp_out = trim($dfout[0]);
         }

         return $temp_out;
}

How can I save this so it doesn't get overwritten every time I update pfSense?

Also I have WGXepc and serialbandaid.sh in /usr/local/bin but they get deleted as well… in /etc/rc I have WGXepc turning off my backlight and running serialbandaid.sh before the 'exit 0'...and in beep.sh I have it turning the Arm/Disarm LED to green on 'start' and to red on 'stop'