Temperature Widget

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

strumf666

Recompile? I'm a freebsd/linux n00b :)

m4f1050

I was using a free shell account when I was trying to compile a wifi adapter driver and they were FreeBSD 8.3 which is why it wouldn't work on pf 2.0.1 but the have upgraded to 9.0 now :-/ I found one with FreeBSD 8.1 and I got the wifi working but access point didn't work so I went and got a TP Link 851 and finished my wireless ap project.

You can look for a free shell maybe you get lucky..