Temperature Widget

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'

jimp

Finally got back around to this…
https://github.com/bsdperimeter/pfsense/commit/f60156f68f615dc137391f3a909a0ee7a0c3c003

strumf666

Is this in the newest snapshot? Is there a cpu frequency widget also available? I am curious if cool&quiet is working.
Is anybody using e-350 and is able to read temperatures? I am using e35m1-m pro but I can't see temps with neither coretemp or amdtemp…

jimp

There hasn't been a new snapshot in the last couple days, we're sorting out some issues with ipfw patches to get CP bandwidth counting working properly

stephenw10

amdtemp was patched for Brazos compatibility in Feb this year:
http://www.freebsd.org/cgi/query-pr.cgi?pr=156358
And was in fact tested as working specifically on the E35M1-M Pro. :)

Steve

Edit: BUT it looks like only for FreeBSD 9. :(

Edit: Ok some confusion from me!
It looks like a different, much larger, patch was added in Feb to support Brazos among other things. However it was applied to /head and didn't make it into the 8 tree.
The originally suggested (and tested) patch against 8.2 simply added the PCI IDs to the driver so that would be easy to apply yourself.

strumf666

I just add the red text to the amdtemp.c?

stephenw10

That's what I would try.
You will need a FreeBSD 8.3 machine to recompile it on of course.

Steve