Temperature Widget
-
I have D2500CC Intel board (Intel(R) Atom(TM) CPU D2500 @ 1.86GHz )
My current snapshot is based on FreeBSD 8.1-RELEASE-p6. I've tried coretemp and mbmon with no luck, I can't see temperatures at all, any suggestions would be great! -
hoi - providing the different temperature modules in /boot would help greatly as systctl needs them.
joe Cowboy, do you plan to commit these ?Edit: or does anyone know, if we want to compile them while building ?
Another option is to let the User decide, as the author of mbmon says that permanently polling the io ports directly can affect system stability.As for the patch - I nearly
finished the widgets code today and test with a cat on a local file cause im using acpi which runs fine and stable for me.
I have some outstanding rl work in the next two days but if anyone's interested in testing i can post a patch by wednesday here. -
On a different note: still have trouble believing that my tiny D510 Atom CPU truly runs at 31-34C
The coretemp temperature is notoriously unreliable in absolute terms. The figure returned by the CPU is a number related to the difference between the current temperature and the TJmax, the maximum allowable junction temperature. Unfortunately TJmax varies between CPUs and most are not known. If you look through the output from coretemp you will probably see something like:
TJmax unknown, assuming 100°C. The atom has a high TJmax as it's intended for laptops, thus the difference figure is larger and a lower absolute value is shown. (Edit: In fact is does seem to be 100°C for the D510 but get the idea! ::))It's possible to tell it what TJmax should be to get a more accurate reading. However the biggest advantage to having this figure on the dashboard is so you can see relative temperature. When a blade falls off your fan you will see a rise!
Steve
-
Hi all - i have a question regarding repetition and backward references in PCCRE - Maybe there are some skilled regexp fans out there…
the following regexp works:
preg_match("/^Temp.=\s(.*);.*/",$arr_mbmon_raw[0],$arr_mbmon); // substr sensor $arr_mbmon = preg_split("/[, ]+/",$arr_mbmon[1]); // get sensors ...I will leave it as is, cause its more readable - but does anyone now how to solve that just with a preg_match, backward refs and quantifiers in a scalable way ?
q2 -> i think that we have to do a telnet on the mbmon provided port - since i doesnt have a machine wherer mbmon runs - could anyone that wants mbmon to run provide the output of a telnet to his mbmon port ?
hanD - Tho
-
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 :-)
-
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?
-
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.
-
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.
-
You cat get the features from /var/run/dmesg.boot, assuming it actually shows up there.
If it does, it should be easy.
-
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=0x803035On 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.
-
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
-
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.
-
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.
-
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!
-
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".
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.
-
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…)
-
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.
-
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. -
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.. -
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.
