The scope of this post is to make use of the onboard voltage and temperature sensors that can be useful to avoid dangerous operating conditions such as overheating.
In order to make them work, compiling a recent kernel was necessary so I first obtained the latest version from kernel.org (2.6.34 as of today).
On EN12000EG, the following hardware supports built-in sensors:
- Temperature sensor in VIA Eden CPU;
- Winbond W83697 SuperIO chip featuring power supply voltage and temperature readings. Link to datasheet is here.
The following kernel options have to be set (followed by the actual name of the option in the .config file):
- ISA support: CONFIG_ISA=y
- hardware monitoring support: CONFIG_HWMON=y
- VID support: CONFIG_HWMON_VID=y
- VIA CPU temp sensor support: CONFIG_SENSORS_VIA_CPUTEMP=y
- Winbond driver: CONFIG_SENSORS_W83627HF=y
- the ACPI drivers: CONFIG_THERMAL=y and CONFIG_THERMAL_HWMON=y
Note: these can be compiled as modules as well, in which case OPTION=m will be in the at the corresponding line.
Next, obtain latest lm-sensors (as of today, it is 3.1.2). Manual for compiling and installing is together with the source, it worked without any problem. Then the sensors can be detected with the sensors-detect tool.
If the options above were compiled as modules, then the following two lines should be add to /etc/modules.conf:
w83627hf
via_cputemp
which will cause the kernel to load these modules on startup.
We are almost ready, however because of recent changes in the kernel architecture (specific version is 2.6.31), some sensors cannot be read because the ACPI code claims the corresponding resources. More information and discussion on the topic is here. The point is, that if we try to load the module for the Winbond chip:
# modprobe w83627hf
we get a "FATAL: [...] Device or resource busy" error message.
The solution is considered to be dangerous, however, I did not notice any problem (yet :)): The option "acpi_enforce_resources=lax" has to be add to the kernel command line upon boot. For grub, this means that the default item in /boot/grub/menu.lst will look something like:
title Debian GNU/Linux, kernel 2.6.34 for VIA C7 and lm-sensors
root (hd0,0)
kernel /boot/vmlinuz-2.6.34 root=/dev/sdb1 ro acpi_enforce_resources=lax
Now the modules should be able to load, and raw sensor values should read using
$ sensors
Yet, the actual voltage readings need to be calculated using the scheme provided in /etc/sensors3.conf and running sensors -s (as root!) to get the proper readings afterwards.
It is interesting, that for older versions of lm-sensors, the Winbond chip was included in the config file, but it is removed from the latest one. No problem, one can just copy it back:
The rest of the sample config file can even be removed, it makes no use. I also modified the limits of the line in7 as the standby 5V (5VSB) reading is known to scatter more than the others, so +/- 10% is more appropriate.
Note: I am aware that now the lm-sensor policy is that platform-specific configuration is supposed to be in /etc/sensors.d, yet I believe that this way is easier. Moreover, I am not aware of any database that could be used for this purpose, and I have no idea what triggered this change of functionality.
Another issue is that I cannot set the limits nor the type of temperature sensors, so lines in the config file like:
set temp1 1
set set temp1_over 80
set temp1_hyst 75
will result in something like:
# sensors -s
Error: File /etc/sensors3.conf, line 95: Unknown feature name
w83697hf-isa-0290: No such subfeature known
Not only the limits but the sensor type cannot be set as well, therefore the second temperature sensor (temp2) always reads false values below even room temperature. I am not aware of the resolution of this issue, but I will update the post as soon as I find the proper solution.
Omitting the invalid lines, now we get the actual readings:
# sensors -s
$ sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +15.5°C (crit = +120.0°C)
w83697hf-isa-0290
Adapter: ISA adapter
VCore: +0.83 V (min = +0.59 V, max = +1.20 V)
+3.3V: +3.31 V (min = +3.14 V, max = +3.47 V)
+5V: +5.11 V (min = +4.76 V, max = +5.24 V)
+12V: +12.34 V (min = +10.82 V, max = +13.19 V)
-12V: -14.83 V (min = -13.18 V, max = -10.80 V) ALARM
-5V: -7.66 V (min = -5.25 V, max = -4.75 V) ALARM
V5SB: +5.46 V (min = +4.49 V, max = +5.51 V)
VBat: +3.22 V (min = +2.40 V, max = +3.60 V)
fan1: 0 RPM (min = -1 RPM, div = 4) ALARM
fan2: 0 RPM (min = 2109 RPM, div = 4) ALARM
temp1: +55.0°C (high = +12.0°C, hyst = +2.0°C) ALARM sensor = transistor
temp2: +15.5°C (high = +120.0°C, hyst = +115.0°C) sensor = diode
beep_enable:enabled
via_cputemp-isa-0000
Adapter: ISA adapter
Core 0: +50.0°C
Note that temp2 and the ACPI virtual device has the same reading, both wrong. For temp2 the quick and dirty solution is to simply ignore it by uncommenting the following line in sensors3.conf:
ignore temp2
The rest however works now, so the only thing to do is to make sure that sensors -s is run on every boot of the system. A simple shell script shall do the trick:
#! /bin/sh
SENSORS=/usr/local/bin/sensors
#just initializing lm-sensors
$SENSORS --version
$SENSORS -s
$SENSORS
Save it as Sensors.sh in /etc/init.d then chmod it to be executable and link it /etc/rc2.d/S40sensors:
# chmod a+x Sensors.sh
# ln -s /etc/init.d/Sensors.sh /etc/rc2.d/S40sensors
Still, there are remaining issues with the lm-sensors that need to be resolved. For instance, the temp2 and acpitz-virtual-0 readings are both wrong, and you cannot even get rid of the second one! At least there is not option to disable it through /etc/sensors3.conf most likely, the corresponding kernel module needs to be unloaded. Also, the spurious readings of the -12V, -5V lines might not be the real things as most likely they not even used by the motherboard. It also worth mentioning that the new kernel policy of claiming all ACPI related resources resulting in the device drivers not to work anymore might need to be reconsidered, as this is a definite loss of functionality as well, resulting in additional hacking being necessary.
No comments:
Post a Comment