12.6.10

VIA Epia Homeserver Project - On-board Sensor Readings

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:

  • chip "w83697hf-*"

  • # no in1 on this chip.
  •     label in0 "VCore"    
  •     label in2 "+3.3V"
  •     label in3 "+5V"
  •     label in4 "+12V"
  •     label in5 "-12V"
  •     label in6 "-5V"
  •     label in7 "V5SB"
  •     label in8 "VBat"


  •     compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
  •     compute in4 ((28/10)+1)*@  ,  @/((28/10)+1)
  •     compute in5 (5.14 * @) - 14.91  ,  (@ + 14.91) / 5.14
  •     compute in6 (3.14 * @) -  7.71  ,  (@ +  7.71) / 3.14
  •     compute in7 ((6.8/10)+1)*@ ,  @/((6.8/10)+1) 


  • # 697HF does not have VID inputs so you MUST set your core
  • # voltage limits below. Currently set for 1.8V core.
  • #               vvv
  •    set in0_min 0.6
  •    set in0_max 1.2
  •    set in2_min 3.3 * 0.95
  •    set in2_max 3.3 * 1.05
  •    set in3_min 5.0 * 0.95
  •    set in3_max 5.0 * 1.05
  •    set in4_min 12 * 0.90
  •    set in4_max 12 * 1.10
  •    set in5_max -12 * 0.90
  •    set in5_min -12 * 1.10
  •    set in6_max -5 * 0.95
  •    set in6_min -5 * 1.05
  •    set in7_min 5 * 0.90
  •    set in7_max 5 * 1.10
  •    set in8_min 3.0 * 0.80
  •    set in8_max 3.0 * 1.20

  • #   ignore temp2


  • 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.