MRTG lang=C why and howto

In my previous post on MRTG, I showed how to plot various sensor and network traffic readings so that they can be easily visualized. In modern systems one can however run into another problem: in UTF-8 enviroments, MRTG starts to complain: 

~#:echo $LANG 

en_us.UTF-8 

~#:mrtg 

ERROR: Mrtg will most likely not work propperly when the environment
variable LANG is set to UTF-8. Please run mrtg in an environment
where this is not the case:

env LANG=C /usr/bin/mrtg

So we shall use the command line given above. However, simply setting LANG=C turns out not be enough, and we get further error messages with previously working mrtg.cfg file such as follows: 

~#:env LANG=C /bin/mrtg /etc/mrtg/mrtg.cfg --logging /var/log/mrtg.log 

...

2010-11-26 16:05:22 -- SNMPGET Problem for hrSystemUptime.0 sysName on public@localhost
 at /bin/mrtg line 658
2010-11-26 16:05:22 -- 2010-11-26 16:05:12: ERROR: Target[localhost.cpu0][_IN_] ' $target->[1]{$mode} ' did not eval into defined data
2010-11-26 16:05:22 -- 2010-11-26 16:05:12: ERROR: Target[localhost.cpu0][_OUT_] ' $target->[1]{$mode} ' did not eval into defined data
2010-11-26 16:05:32 -- SNMP Error: 

no response received

The problem turns out to be that the textual SNMP targets do not work anymore, and the numeric OIDs such as .1.3.6.1.2.1.25.3.3.1.2.768 have to be put in mrtg.cfg. Not only this is inconvenient, the proper numeric values have to be found as well. In order to do so, the snmptranslate tool can be used:

~#: snmptranslate HOST-RESOURCES-MIB::hrProcessorLoad.768 -On

.1.3.6.1.2.1.25.3.3.1.2.768

Here the main point is the -On switch, which translates the name of the OID to the corresponding numerical value. All textual targets in mrtg.cfg must be replaced using the output of this tool. This includes the previously discussed lm-sensors outputs as well. Here is an example for CPU usage:

# commented old one

#Target[localhost.cpu0]: hrProcessorLoad.768&hrProcessorLoad.768:public@localhost
#new one follows

Target[localhost.cpu0]:.1.3.6.1.2.1.25.3.3.1.2.768&.1.3.6.1.2.1.25.3.3.1.2.768:public@localhost 

and then MRTG works again!

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.

WD MyBook Hacks - Temperature Readings

This is a topic that puzzled me for some time. Built-in temperature sensors are useful for monitoring the health status of the device and making proper action if for instance overheating occurs. For personal computing, lm-sensors is a frequently-used tool for this purpose which is able to read the sensors via SMBus on most of the motherboards. However, the MyBook has a different facility for this, so we will see how to take advantage of it. In fact, not only the on-board temperature sensor can be read, but the one on the hard drive can be used as well.

Reading sensor on the hard drive

This sensor can simply be reached through reading the S.M.A.R.T. data of the drive as I posted earlier. What we need to do is to grep the useful data and get rid of the garbage by selecting the line and the field we are interested in:

#~: smartctl -a -d ata /dev/sda | awk '/Temperature/ {print $10}'

44

will do the job, and we get the temperature of the hard drive in Celsius.

Reading the on-board temperature sensor

This one can be interrogated through:

#~: cat /sys/module/thermAndFan/parameters/current_temp

27

which is a reasonable value. If however we look further into the details:

#~: cat /sys/module/thermAndFan/parameters/hot_limit

16

#~: cat /sys/module/thermAndFan/parameters/cold_limit

104

this should give the clue that this is not a direct temperature reading. Indeed this sensor does not read in Celsius but rather in "Counts" which is proportional to the sensor resistance value. Luckily enough google finds the lookup table for this platform here (see TvsCnt[] array). As the sensor is a semiconductor thermistor, there is no simple linear equation to determine the temperature, rather the following exponential dependence should be used: Cnt=a×exp(b/T), with Cnt being the reading above and T being the absolute temperature in Kelvin. For this specific sensor the parameters are a=1/9331 and b=3865 as a result by a simple fitting procedure. So after some algebra we find that the temperature will be: t=3865/(ln(Cnt)+9.1411)-273.16 in Celsius (feel free to do it in Fahrenheit :) ).

In order to implement this equation, we will use the command-line calc tool:

#~: ipkg install calc

Finally using this tool a simple script can be used to determine the temperature:

#!/bin/sh

Y1=`cat /sys/module/thermAndFan/parameters/current_temp `

C1='display(0);config("tilde","off");3865/(ln('
C2=')+9.1411)-273.16'
/opt/bin/calc $C1$Y1$C2 | awk 'NR==3 {print $1}'  

which results in a single return value, e. g. 37.

Finally the question remains: Why would we do this? The reason is that these readings can be plotted using for instance MRTG, so that the health status of the storage can be checked easily.