1sensors.conf(5) Linux User's Manual sensors.conf(5)
2
6 sensors.conf - libsensors configuration file
7
10 sensors.conf describes how libsensors, and so all programs using it,
11 should translate the raw readings from the kernel modules to real-world
12 values.
13
16 On a given system, there may be one or more hardware monitoring chips.
17 Each chip may have several features. For example, the LM78 monitors 7
18 voltage inputs, 3 fans and one temperature. Feature names are standard‐
19 ized. Typical feature names are in0, in1, in2... for voltage inputs,
20 fan1, fan2, fan3... for fans and temp1, temp2, temp3... for temperature
21 inputs.
22 Each feature may in turn have one or more sub-features, each represent‐
24 ing an attribute of the feature: input value, low limit, high limit,
25 alarm, etc. Sub-feature names are standardized as well. For example,
26 the first voltage input (in0) would typically have sub-features
27 in0_input (measured value), in0_min (low limit), in0_max (high limit)
28 and in0_alarm (alarm flag). Which sub-features are actually present
29 depend on the exact chip type.
30 The sensors.conf configuration file will let you configure each chip,
32 feature and sub-feature in a way that makes sense for your system.
33 The rest of this section describes the meaning of each configuration
35 statement.
36 CHIP STATEMENT
39 A chip statement selects for which chips all following compute, label,
40 ignore and set statements are meant. A chip selection remains valid
41 until the next chip statement. Example:
42 chip "lm78-*" "lm79-*"
44 If a chip matches at least one of the chip descriptions, the following
46 configuration lines are examined for it, otherwise they are ignored.
47 A chip description is built from several elements, separated by dashes.
49 The first element is the chip type, the second element is the name of
50 the bus, and the third element is the hexadecimal address of the chip.
51 Such chip descriptions are printed by sensors(1) as the first line for
52 every chip.
53 The name of the bus is either isa, pci, virtual, spi-* or i2c-N with N
55 being a bus number as bound with a bus statement. This list isn't nec‐
56 essarily exhaustive as support for other bus types may be added in the
57 future.
58 You may substitute the wildcard operator * for every element. Note how‐
60 ever that it wouldn't make any sense to specify the address without the
61 bus type, so the address part is plain omitted when the bus type isn't
62 specified. Here is how you would express the following matches:
63 LM78 chip at address 0x2d on I2C bus 1 lm78-i2c-1-2d
66 LM78 chip at address 0x2d on any I2C bus lm78-i2c-*-2d
68 LM78 chip at address 0x290 on the ISA bus lm78-isa-0290
69 Any LM78 chip on I2C bus 1 lm78-i2c-1-*
70 Any LM78 on any I2C bus lm78-i2c-*-*
71 Any LM78 chip on the ISA bus lm78-isa-*
72 Any LM78 chip lm78-*
73 Any chip at address 0x2d on I2C bus 1 *-i2c-1-2d
74 Any chip at address 0x290 on the ISA bus *-isa-0290
75 If several chip statements match a specific chip, they are all consid‐
77 ered.
78 LABEL STATEMENT
81 A label statement describes how a feature should be called. Features
82 without a label statement are just called by their feature name. Appli‐
83 cations can use this to label the readings they present. Example:
84 label in3 "+5V"
86 The first argument is the feature name. The second argument is the fea‐
88 ture description.
89 IGNORE STATEMENT
92 An ignore statement is a hint that a specific feature should be ignored
93 - probably because it returns bogus values (for example, because a fan
94 or temperature sensor is not connected). Example:
95 ignore fan1
97 The only argument is the feature name. Please note that this does not
99 disable anything in the actual sensor chip; it simply hides the feature
100 in question from libsensors users.
101 COMPUTE STATEMENT
104 A compute statement describes how a feature's raw value should be
105 translated to a real-world value, and how a real-world value should be
106 translated back to a raw value again. This is most useful for voltage
107 sensors, because in general sensor chips have a limited range and volt‐
108 ages outside this range must be divided (using resistors) before they
109 can be monitored. Example:
110 compute in3 ((6.8/10)+1)*@, @/((6.8/10)+1)
112 The example above expresses the fact that the voltage input is divided
114 using two resistors of values 6.8 Ohm and 10 Ohm, respectively. See the
115 VOLTAGE COMPUTATION DETAILS section below for details.
116 The first argument is the feature name. The second argument is an
118 expression which specifies how a raw value must be translated to a
119 real-world value; `@' stands here for the raw value. This is the for‐
120 mula which will be applied when reading values from the chip. The third
121 argument is an expression that specifies how a real-world value should
122 be translated back to a raw value; `@' stands here for the real-world
123 value. This is the formula which will be applied when writing values to
124 the chip. The two formulas are obviously related, and are separated by
125 a comma.
126 A compute statement applies to all sub-features of the target feature
128 for which it makes sense. For example, the above example would affect
129 sub-features in3_min and in3_max (which are voltage values) but not
130 in3_alarm (which is a boolean flag.)
131 The following operators are supported in compute statements:
133 + - * / ( ) ^ `
134 ^x means exp(x) and `x means ln(x).
135 You may use the name of sub-features in these expressions; current
137 readings are substituted. You should be careful though to avoid circu‐
138 lar references.
139 If at any moment a translation between a raw and a real-world value is
141 called for, but no compute statement applies, a one-on-one translation
142 is used instead.
143 SET STATEMENT
146 A set statement is used to write a sub-feature value to the chip. Of
147 course not all sub-feature values can be set that way, in particular
148 input values and alarm flags can not. Valid sub-features are usually
149 min/max limits. Example:
150 set in3_min 5 * 0.95
152 set in3_max 5 * 1.05
153 The example above basically configures the chip to allow a 5% deviance
155 for the +5V power input.
156 The first argument is the feature name. The second argument is an
158 expression which determines the written value. If there is an applying
159 compute statement, this value is fed to its third argument to translate
160 it to a raw value.
161 You may use the name of sub-features in these expressions; current
163 readings are substituted. You should be careful though to avoid circu‐
164 lar references.
165 Please note that set statements are only executed by sensors(1) when
167 you use the -s option. Typical graphical sensors applications do not
168 care about these statements at all.
169 BUS STATEMENT
172 A bus statement binds the description of an I2C or SMBus adapter to a
173 bus number. This makes it possible to refer to an adapter in the con‐
174 figuration file, independent of the actual correspondence of bus num‐
175 bers and actual adapters (which may change from moment to moment).
176 Example:
177 bus "i2c-0" "SMBus PIIX4 adapter at e800"
179 The first argument is the bus number. It is the literal text i2c-, fol‐
181 lowed by a number. As there is a dash in this argument, it must always
182 be quoted.
183 The second argument is the adapter name, it must match exactly the
185 adapter name as it appears in /sys/class/i2c-adapter/i2c-*/name. It
186 should always be quoted as well as it will most certainly contain spa‐
187 ces or dashes.
188 The bus statements may be scattered randomly throughout the configura‐
190 tion file; there is no need to place the bus line before the place
191 where its binding is referred to. Still, as a matter of good style, we
192 suggest you place all bus statements together at the top of your con‐
193 figuration file.
194 Running sensors --bus-list will generate these lines for you.
196 In the case where multiple configuration files are used, the scope of
198 each bus statement is the configuration file it was defined in. This
199 makes it possible to have bus statements in all configuration files
200 which will not unexpectedly interfere with each other.
201 STATEMENT ORDER
204 Statements can go in any order, however it is recommended to put `set
205 fanX_div' statements before `set fanX_min' statements, in case a driver
206 doesn't preserve the fanX_min setting when the fanX_div value is
207 changed. Even if the driver does, it's still better to put the state‐
208 ments in this order to avoid accuracy loss.
209
212 Most voltage sensors in sensor chips have a range of 0 to 4.08 V. This
213 is generally sufficient for the +3.3V and CPU supply voltages, so the
214 sensor chip reading is the actual voltage.
215 Other supply voltages must be scaled with an external resistor network.
217 The driver reports the value at the chip's pin (0 - 4.08 V), and the
218 userspace application must convert this raw value to an actual voltage.
219 The compute statements provide this facility.
220 Unfortunately the resistor values vary among motherboard types. There‐
222 fore you have to figure out the correct resistor values for your own
223 motherboard.
224 For positive voltages (typically +5V and +12V), two resistors are used,
226 with the following formula:
227 R1 = R2 * (Vs/Vin - 1)
228 where:
230 R1 and R2 are the resistor values
231 Vs is the actual voltage being monitored
232 Vin is the voltage at the pin
233 This leads to the following compute formula:
235 compute inX @*((R1/R2)+1), @/(((R1/R2)+1)
236 Real-world formula for +5V and +12V would look like:
238 compute in3 @*((6.8/10)+1), @/((6.8/10)+1)
239 compute in4 @*((28/10)+1), @/((28/10)+1)
240 For negative voltages (typically -5V and -12V), two resistors are used
242 as well, but different boards use different strategies to bring the
243 voltage value into the 0 - 4.08 V range. Some use an inverting ampli‐
244 fier, others use a positive reference voltage. This leads to different
245 computation formulas. Note that most users won't have to care because
246 most modern motherboards make little use of -12V and no use of -5V so
247 they do not bother monitoring these voltage inputs.
248 Real-world examples for the inverting amplifier case:
250 compute in5 -@*(240/60), -@/(240/60)
251 compute in6 -@*(100/60), -@/(100/60)
252 Real-world examples for the positive voltage reference case:
254 compute in5 @*(1+232/56) - 4.096*232/56, (@ +
255 4.096*232/56)/(1+232/56)
256 compute in6 @*(1+120/56) - 4.096*120/56, (@ +
257 4.096*120/56)/(1+120/56)
258 Many recent monitoring chips have a 0 - 2.04 V range, so scaling resis‐
260 tors are even more needed, and resistor values are different.
261 There are also a few chips out there which have internal scaling resis‐
263 tors, meaning that their value is known and doesn't change from one
264 motherboard to the next. For these chips, the driver usually handles
265 the scaling so it is transparent to the user and no compute statements
266 are needed.
267
270 On top of the usual features, temperatures can have two specific
271 sub-features: temperature sensor type (tempX_type) and hysteresis val‐
272 ues (tempX_max_hyst and tempX_crit_hyst).
273 THERMAL SENSOR TYPES
276 Available thermal sensor types:
277 1 PII/Celeron Diode
279 2 3904 transistor
280 3 thermal diode
281 4 thermistor
282 5 AMD AMDSI
283 6 Intel PECI
284 For example, to set temp1 to thermistor type, use:
286 set temp1_type 4
288 Only certain chips support thermal sensor type change, and even these
290 usually only support some of the types above. Please refer to the spe‐
291 cific driver documentation to find out which types are supported by
292 your chip.
293 In theory, the BIOS should have configured the sensor types correctly,
295 so you shouldn't have to touch them, but sometimes it isn't the case.
296 THERMAL HYSTERESIS MECHANISM
299 Many monitoring chips do not handle the high and critical temperature
300 limits as simple limits. Instead, they have two values for each limit,
301 one which triggers an alarm when the temperature rises and another one
302 which clears the alarm when the temperature falls. The latter is typi‐
303 cally a few degrees below the former. This mechanism is known as hys‐
304 teresis.
305 The reason for implementing things that way is that high temperature
307 alarms typically trigger an action to attempt to cool the system down,
308 either by scaling down the CPU frequency, or by kicking in an extra
309 fan. This should normally let the temperature fall in a timely manner.
310 If this was clearing the alarm immediately, then the system would be
311 back to its original state where the temperature rises and the alarm
312 would immediately trigger again, causing an undesirable tight fan on,
313 fan off loop. The hysteresis mechanism ensures that the system is
314 really cool before the fan stops, so that it will not have to kick in
315 again immediately.
316 So, in addition to tempX_max, many chips have a tempX_max_hyst sub-fea‐
318 ture. Likewise, tempX_crit often comes with tempX_max_crit. Example:
319 set temp1_max 60
321 set temp1_max_hyst 56
322 The hysteresis mechanism can be disabled by giving both limits the same
324 value.
325
328 Some chips support alarms with beep warnings. When an alarm is trig‐
329 gered you can be warned by a beeping signal through your computer
330 speaker. On top of per-feature beep flags, there is usually a master
331 beep control switch to enable or disable beeping globally. Enable beep‐
332 ing using:
333 set beep_enable 1
335 or disable it using:
337 set beep_enable 0
339
342 If more than one statement of the same kind applies at a certain
343 moment, the last one in the configuration file is used. So usually, you
344 should put more general chip statements at the top, so you can overrule
345 them below.
346
349 Comments are introduced by hash marks. A comment continues to the end
350 of the line. Empty lines, and lines containing only whitespace or com‐
351 ments are ignored. Other lines have one of the below forms. There must
352 be whitespace between each element, but the amount of whitespace is
353 unimportant. A line may be continued on the next line by ending it with
354 a backslash; this does not work within a comment, NAME or NUMBER.
355 bus NAME NAME NAME
357 chip NAME-LIST
358 label NAME NAME
359 compute NAME EXPR , EXPR
360 ignore NAME
361 set NAME EXPR
362 A NAME is a string. If it only contains letters, digits and under‐
364 scores, it does not have to be quoted; in all other cases, you must use
365 double quotes around it. Within quotes, you can use the normal
366 escape-codes from C.
367 A NAME-LIST is one or more NAME items behind each other, separated by
369 whitespace.
370 A EXPR is of one of the below forms:
372 NUMBER
374 NAME
375 @
376 EXPR + EXPR
377 EXPR - EXPR
378 EXPR * EXPR
379 EXPR / EXPR
380 - EXPR
381 ^ EXPR
382 ` EXPR
383 ( EXPR )
384 A NUMBER is a floating-point number. `10', `10.4' and `.4' are examples
386 of valid floating-point numbers; `10.' or `10E4' are not valid.
387
390 /etc/sensors3.conf
391 /etc/sensors.conf
392 The system-wide libsensors(3) configuration file. /etc/sen‐
393 sors3.conf is tried first, and if it doesn't exist, /etc/sen‐
394 sors.conf is used instead.
395 /etc/sensors.d
397 A directory where you can put additional libsensors configura‐
398 tion files. Files found in this directory will be processed in
399 alphabetical order after the default configuration file. Files
400 with names that start with a dot are ignored.
401
404 libsensors(3)
405
408 Frodo Looijaard and the lm_sensors group http://www.lm-sensors.org/
409lm-sensors 3 February 2009 sensors.conf(5)