Difference between revisions of "Lm sensors"

From ArchWiki
Jump to: navigation, search
m
m (style)
 
(56 intermediate revisions by 18 users not shown)
Line 1: Line 1:
 +
{{DISPLAYTITLE:lm_sensors}}
 
[[Category:Status monitoring and notification]]
 
[[Category:Status monitoring and notification]]
 
[[Category:CPU]]
 
[[Category:CPU]]
[[cs:Lm sensors]]
+
[[cs:Lm-sensors]]
[[es:Lm sensors]]
+
[[de:Lm sensors]]
 +
[[es:Lm-sensors]]
 
[[ja:Lm sensors]]
 
[[ja:Lm sensors]]
[[ru:Lm sensors]]
+
[[ru:Lm-sensors]]
[[uk:Lm sensors]]
+
[[uk:Lm-sensors]]
[[zh-CN:Lm sensors]]
+
[[zh-cn:Lm sensors]]
{{lowercase title}}
+
{{Related articles start}}
[http://www.lm-sensors.org/ lm_sensors] (Linux monitoring sensors) is a free and open-source application that provides tools and drivers for monitoring temperatures, voltage, and fans. This document explains how to install, configure, and use lm_sensors so that you can monitor CPU temperatures, motherboard temperatures, and fan speeds.
+
{{Related|Fan speed control}}
 +
{{Related|hddtemp}}
 +
{{Related|monitorix}}
 +
{{Related articles end}}
 +
[http://lm-sensors.org/ lm_sensors] (Linux monitoring sensors) is a free and open-source application that provides tools and drivers for monitoring temperatures, voltage, and fans. This document explains how to install, configure, and use lm_sensors.
  
== Usage ==
+
== Installation ==
=== Installation ===
+
[[Install]] the {{Pkg|lm_sensors}} package.
Install the {{Pkg|lm_sensors}} package from the [[Official Repositories|official repositories]].
+
 
 +
{{Note|More documentation is at the [https://github.com/groeck/lm-sensors/tree/master/doc GitHub repository]. In the future these may be installed, see {{Bug|48354}}.}}
 +
 
 +
== Setup ==
 +
Use ''sensors-detect'' as root to detect and generate a list of kernel modules:
 +
{{Warning|Do not use anything other than the default options (by just hitting {{ic|Enter}}), unless you know exactly what you are doing. See [[#Laptop Screen issues after running sensors-detect]].}}
  
=== Setting up lm_sensors ===
 
Use '''sensors-detect''' to detect and generate a list of kernel modules:
 
 
  # sensors-detect
 
  # sensors-detect
This will create the {{ic|/etc/conf.d/lm_sensors}} configuration file which is used by the {{ic|sensors}} daemon to automatically load kernel modules on boot.  You will be asked if you want to probe for various hardware. The "safe" answers are the defaults, so just hitting {{ic|Enter}} to all the questions will generally not cause any problems.
 
  
When the detection is finished, you will be presented with a summary of the probes. Here is an example summary from my system:
+
It will ask to probe for various hardware. The "safe" answers are the defaults, so just hitting {{ic|Enter}} to all the questions will generally not cause any problems. This will create the {{ic|/etc/conf.d/lm_sensors}} configuration file which is used by {{ic|lm_sensors.service}} to automatically load kernel modules on boot.
 +
 
 +
When the detection is finished, a summary of the probes is presented.
 +
 
 +
Example:
 
{{hc|# sensors-detect|<nowiki>
 
{{hc|# sensors-detect|<nowiki>
Now follows a summary of the probes I have just done.
+
This program will help you determine which kernel modules you need
Just press ENTER to continue:
+
to load to use lm_sensors most effectively. It is generally safe
Driver `it87':
+
and recommended to accept the default answers to all questions,
  * ISA bus, address 0x290
+
unless you know what you're doing.
    Chip `ITE IT8718F Super IO Sensors' (confidence: 9)
+
Driver `coretemp':
+
  * Chip `Intel Core family thermal sensor' (confidence: 9)
+
</nowiki>}}
+
If you plan on using the daemon, be sure to answer '''YES''' when asked if you want to to generate {{ic|/etc/conf.d/lm_sensors}}.
+
  
To automatically load the kernel modules at boot time:
+
Some south bridges, CPUs or memory controllers contain embedded sensors.
# systemctl enable lm_sensors.service
+
Do you want to scan for them? This is totally safe. (YES/no):  
 +
Module cpuid loaded successfully.
 +
Silicon Integrated Systems SIS5595...                      No
 +
VIA VT82C686 Integrated Sensors...                          No
 +
VIA VT8231 Integrated Sensors...                            No
 +
AMD K8 thermal sensors...                                  No
 +
AMD Family 10h thermal sensors...                           No
  
Alternatively, instead of using the daemon, you can add the modules to the {{ic|MODULES}} array in {{ic|/etc/modules-load.d/lm_sensors.conf}}:
+
...
coretemp
+
it87
+
acpi-cpufreq
+
  
=== Automatic lm_sensors deployment ===
+
Now follows a summary of the probes I have just done.
If you wish to deploy lm-sensors on multiple diferent linux machines issue is that sensors-detect ask you quite a few questions. There are few tricks that you can use to automate replies.
+
Just press ENTER to continue:
  
First one is if you wish to accept defaults which sensors-detect suggest you need just to press [ENTER] all the time. To automate this use this one liner:
+
Driver `coretemp':
+
  * Chip `Intel digital thermal sensor' (confidence: 9)
# yes "" | sensors-detect
+
+
If you wish to override defaults and answer YES to all questions then use this oneliner:
+
+
# yes | sensors-detect
+
  
=== Testing your lm_sensors ===
+
Driver `lm90':
To test your setup, load the [[kernel modules]] manually or by using the [[systemd]] service file. You do '''not''' have to do both.
+
  * Bus `SMBus nForce2 adapter at 4d00'
 +
    Busdriver `i2c_nforce2', I2C address 0x4c
 +
    Chip `Winbond W83L771AWG/ASG' (confidence: 6)
  
Example manually adding them:
+
Do you want to overwrite /etc/conf.d/lm_sensors? (YES/no):  
# modprobe it87
+
ln -s '/usr/lib/systemd/system/lm_sensors.service' '/etc/systemd/system/multi-user.target.wants/lm_sensors.service'
# modprobe coretemp
+
Unloading i2c-dev... OK
Example using the script:
+
Unloading cpuid... OK
# systemctl enable lm_sensors
+
</nowiki>}}
  # systemctl start lm_sensors
+
 
 +
{{Note|A systemd service is automatically enabled if users answer '''YES''' when asked about generating {{ic|/etc/conf.d/lm_sensors}}. Answering '''YES''' also automatically starts the service.}}
  
You should see something like this when you run sensors
+
== Running sensors ==
 +
Example running {{ic|sensors}}:
 
{{hc|$ sensors|<nowiki>
 
{{hc|$ sensors|<nowiki>
 
coretemp-isa-0000
 
coretemp-isa-0000
 
Adapter: ISA adapter
 
Adapter: ISA adapter
Core 0:     +30.0°C  (high = +76.0°C, crit = +100.0°C)
+
Core 0:       +35.0°C  (crit = +105.0°C)
 
+
Core 1:       +32.0°C  (crit = +105.0°C)
coretemp-isa-0001
+
Adapter: ISA adapter
+
Core 1:     +30.0°C  (high = +76.0°C, crit = +100.0°C) 
+
 
+
coretemp-isa-0002
+
Adapter: ISA adapter
+
Core 2:      +32.0°C  (high = +76.0°C, crit = +100.0°C)
+
 
+
coretemp-isa-0003
+
Adapter: ISA adapter
+
Core 3:      +30.0°C  (high = +76.0°C, crit = +100.0°C) 
+
 
+
it8718-isa-0290
+
Adapter: ISA adapter
+
in0:        +1.17 V  (min =  +0.00 V, max =  +4.08 V) 
+
in1:        +1.31 V  (min =  +1.28 V, max =  +1.68 V) 
+
in2:        +3.28 V  (min =  +2.78 V, max =  +3.78 V) 
+
in3:        +2.88 V  (min =  +2.67 V, max =  +3.26 V) 
+
in4:        +2.98 V  (min =  +2.50 V, max =  +3.49 V) 
+
in5:        +1.34 V  (min =  +0.58 V, max =  +1.34 V)  ALARM
+
in6:        +2.02 V  (min =  +1.04 V, max =  +1.36 V)  ALARM
+
in7:        +2.83 V  (min =  +2.67 V, max =  +3.26 V) 
+
Vbat:        +3.28 V
+
fan1:      1500 RPM  (min = 3245 RPM)  ALARM
+
fan2:          0 RPM  (min = 3245 RPM)  ALARM
+
fan3:          0 RPM  (min = 3245 RPM)  ALARM
+
temp1:      +18.0°C  (low  = +127.0°C, high = +64.0°C)  sensor = thermal diode
+
temp2:      +32.0°C  (low  = +127.0°C, high = +64.0°C)  sensor = thermistor
+
temp3:      +38.0°C  (low  = +127.0°C, high = +64.0°C)  sensor = thermistor
+
cpu0_vid:  +2.050 V
+
  
acpitz-virtual-0
+
w83l771-i2c-0-4c
Adapter: Virtual device
+
Adapter: SMBus nForce2 adapter at 4d00
temp1:       +18.0°C  (crit = +64.0°C)
+
temp1:       +28.0°C  (low  = -40.0°C, high = +70.0°C)
 +
                      (crit = +85.0°C, hyst = +75.0°C)
 +
temp2:        +37.4°C  (low  = -40.0°C, high = +70.0°C)
 +
                      (crit = +110.0°C, hyst = +100.0°C)
 
</nowiki>}}
 
</nowiki>}}
  
 
=== Reading SPD values from memory modules (optional) ===
 
=== Reading SPD values from memory modules (optional) ===
  
To read the SPD timing values from your memory modules, install {{pkg|i2c-tools}} from the [[Official Repositories|official repositories]]. Once you have i2c-tools installed, you will need to load the {{ic|eeprom}} [[Kernel_modules|kernel module]].
+
To read the SPD timing values from memory modules, install the {{pkg|i2c-tools}} package. Once installed, load the {{ic|eeprom}} [[kernel module]].
 
  # modprobe eeprom
 
  # modprobe eeprom
Finally, you can view your memory information with {{ic|decode-dimms}}.
 
  
Here is partial output from one machine:
+
Finally, view memory information with {{ic|decode-dimms}}.
{{hc|$ decode-dimms|<nowiki>
+
# decode-dimms version 5733 (2009-06-09 13:13:41 +0200)
+
  
 +
Here is partial output from one machine:
 +
{{hc|# decode-dimms|<nowiki>
 
Memory Serial Presence Detect Decoder
 
Memory Serial Presence Detect Decoder
 
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
 
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Line 174: Line 155:
 
</nowiki>}}
 
</nowiki>}}
  
== Using sensor data ==
+
== Using Sensor Data ==
 
=== Graphical Front-ends ===
 
=== Graphical Front-ends ===
 
There are a variety of front-ends for sensors data.
 
There are a variety of front-ends for sensors data.
 +
*[[conky]] - Conky is an advanced, highly configurable system monitor for X based on torsmo
 
*{{Pkg|xsensors}} - X11 interface to lm_sensors
 
*{{Pkg|xsensors}} - X11 interface to lm_sensors
 +
*{{AUR|psensor}} - GTK+ application for monitoring hardware sensors, including temperatures and fan speeds. Monitors motherboard and CPU (using lm-sensors), Nvidia GPUs (using XNVCtrl), and harddisks (using [[hddtemp]] or libatasmart).
 +
For specific [[Desktop environments]]:
 +
*{{Pkg|sensors-applet}} - applet for the [[GNOME]] Panel to display readings from hardware sensors, including CPU temperature, fan speeds and voltage readings.
 +
*{{AUR|plasma5-applets-thermal-monitor-git}} - Is an example of the [[KDE#Widgets|widgets]] available for [[KDE]] desktop.
 +
*{{AUR|sensors-lxpanel-plugin}} -- A lm_sensors plugin for the [[LXDE]] panel. lxpanel also includes a simple 'Temperature Monitor' plugin.
 
*{{Pkg|xfce4-sensors-plugin}} - A lm_sensors plugin for the [[Xfce]] panel
 
*{{Pkg|xfce4-sensors-plugin}} - A lm_sensors plugin for the [[Xfce]] panel
*[[conky]] - Conky is an advanced, highly configurable system monitor for X based on torsmo
 
*{{Pkg|kdeutils-superkaramba}} - Superkaramba is a tool which gives posibility to create different widgets for KDE desktop. Check the [http://www.kde-look.org/index.php?xcontentmode=38 karamba section on kde-look.org] for examples of making karamba front-ends for sensors data.
 
*{{pkg|sensors-applet}} - applet for the [[GNOME]] Panel to display readings from hardware sensors, including CPU temperature, fan speeds and voltage readings.
 
  
 
=== sensord ===
 
=== sensord ===
There is an optional daemon called sensord (included with the {{Pkg|lm_sensors}} package) which can log your data to a round robin database (rrd) and later visualize graphically.  See the sensord man page for details.
+
There is an optional daemon called sensord (included with the {{Pkg|lm_sensors}} package) which can log data to a round robin database (rrd) and later visualize graphically.  See the sensord man page for details.
 +
 
 +
==Tips and Tricks==
 +
=== Adjusting Values ===
 +
In some cases, the data displayed might be incorrect or users may wish to rename the output.
 +
Use cases include:
 +
* Incorrect temperature values due to a wrong offset (i.e. temps are reported 20 °C higher then actual).
 +
* Users wish to rename the output of some sensors.
 +
* The cores might be displayed in an incorrect order.
 +
 
 +
All of the above (and more) can be adjusted by overriding the package provides settings in {{ic|/etc/sensors3.conf}} by creating {{ic|/etc/sensors.d/foo}} wherein any number of tweaks will override the default values.  It is recommended to rename 'foo' to the motherboard brand and model but this naming nomenclature is optional.
 +
 
 +
{{Note|Do not edit /etc/sensors3.conf directly since package updates will overwrite any changes thus losing them.}}
 +
 
 +
==== Example 1. Adjusting Temperature Offsets ====
 +
This is a real example on a Zotac ION-ITX-A-U motherboard.  The coretemp values are off by 20 °C (too high) and are adjusted down to Intel specs.
  
==Troubleshooting==
+
{{hc|$ sensors|<nowiki>
=== Renumbering Cores for Multi-CPU Systems ===
+
coretemp-isa-0000
In rare cases, the actual numbering of physical cores on multi-processor motherboards can be incorrect.  Consider the following HP Z600 workstation with dual Xeons:
+
Adapter: ISA adapter
 +
Core 0:      +57.0°C  (crit = +125.0°C)
 +
Core 1:      +55.0°C  (crit = +125.0°C)
 +
...
 +
</nowiki>}}
 +
 
 +
Run {{ic|sensors}} with the {{ic|-u}} switch to see what options are available for each physical chip (raw mode):
 +
{{hc|$ sensors -u|<nowiki>
 +
coretemp-isa-0000
 +
Adapter: ISA adapter
 +
Core 0:
 +
  temp2_input: 57.000
 +
  temp2_crit: 125.000
 +
  temp2_crit_alarm: 0.000
 +
Core 1:
 +
  temp3_input: 55.000
 +
  temp3_crit: 125.000
 +
  temp3_crit_alarm: 0.000
 +
...
 +
</nowiki>}}
 +
 
 +
Create the following file overriding the default values:
 +
{{hc|/etc/sensors.d/Zotac-IONITX-A-U|<nowiki>
 +
chip "coretemp-isa-0000"
 +
  label temp2 "Core 0"
 +
  compute temp2 @-20,@-20
 +
 
 +
  label temp3 "Core 1"
 +
  compute temp3 @-20,@-20
 +
</nowiki>}}
 +
 
 +
Now invoking {{ic|sensors}} shows the adjust values:
 +
{{hc|$ sensors|<nowiki>
 +
coretemp-isa-0000
 +
Adapter: ISA adapter
 +
Core 0:      +37.0°C  (crit = +105.0°C)
 +
Core 1:      +35.0°C  (crit = +105.0°C)
 +
...
 +
</nowiki>}}
 +
 
 +
==== Example 2. Renaming Labels ====
 +
This is a real example on an Asus A7M266.  The user wishes more verbose names for the temperature labels 'temp1' and 'temp2':
 +
{{hc|$ sensors|<nowiki>
 +
as99127f-i2c-0-2d
 +
Adapter: SMBus Via Pro adapter at e800
 +
...
 +
temp1:        +35.0°C  (high =  +0.0°C, hyst = -128.0°C)
 +
temp2:        +47.5°C  (high = +100.0°C, hyst = +75.0°C)
 +
...
 +
</nowiki>}}
 +
 
 +
Create the following file to override the default values:
 +
{{hc|/etc/sensors.d/Asus_A7M266|<nowiki>
 +
chip "as99127f-*"
 +
  label temp1 "Mobo Temp"
 +
  label temp2 "CPU0 Temp"
 +
</nowiki>}}
 +
 
 +
Now invoking {{ic|sensors}} shows the adjust values:
 +
{{hc|$ sensors|<nowiki>
 +
as99127f-i2c-0-2d
 +
Adapter: SMBus Via Pro adapter at e800
 +
...
 +
Mobo Temp:        +35.0°C  (high =  +0.0°C, hyst = -128.0°C)
 +
CPU0 Temp:        +47.5°C  (high = +100.0°C, hyst = +75.0°C)
 +
...
 +
</nowiki>}}
 +
 
 +
==== Example 3. Renumbering Cores for Multi-CPU Systems ====
 +
This is a real example on an HP Z600 workstation with dual Xeons.  The actual numbering of physical cores is incorrect: numbered 0, 1, 9, 10 which is repeated into the second CPUMost users expect the core temperatures to report out in sequential order, i.e. 0,1,2,3,4,5,6,7.
 
{{hc|$ sensors|<nowiki>
 
{{hc|$ sensors|<nowiki>
 
coretemp-isa-0000
 
coretemp-isa-0000
Line 203: Line 271:
 
Core 9:      +60.0°C  (high = +85.0°C, crit = +95.0°C)
 
Core 9:      +60.0°C  (high = +85.0°C, crit = +95.0°C)
 
Core 10:      +61.0°C  (high = +85.0°C, crit = +95.0°C)
 
Core 10:      +61.0°C  (high = +85.0°C, crit = +95.0°C)
 
+
...
smsc47b397-isa-0480
+
Adapter: ISA adapter
+
fan1:        1730 RPM
+
fan2:        1746 RPM
+
fan3:        1224 RPM
+
fan4:        2825 RPM
+
temp1:        +46.0°C
+
temp2:        +37.0°C
+
temp3:        +23.0°C
+
temp4:      -128.0°C
+
 
</nowiki>}}
 
</nowiki>}}
  
Note the cores are numbered 0, 1, 9, 10 which is repeated into the second CPU.  Most users want the core temperatures to report out in sequential order, i.e. 0,1,2,3,4,5,6,7.  Fixing the order is accomplished in two steps.
+
Again, run {{ic|sensors}} with the {{ic|-u}} switch to see what options are available for each physical chip:
 
+
====Step 1. ID what each chip is reporting ====
+
 
+
Run {{ic|sensors}} with the {{ic|-u}} switch to see what options are available for each physical chip:
+
  
 
{{hc|$ sensors -u coretemp-isa-0000|<nowiki>
 
{{hc|$ sensors -u coretemp-isa-0000|<nowiki>
Line 266: Line 320:
 
   temp12_max: 85.000
 
   temp12_max: 85.000
 
   temp12_crit: 95.000
 
   temp12_crit: 95.000
 +
...
 
</nowiki>}}
 
</nowiki>}}
  
==== Step 2. Redefine the cores ====
+
Create the following file overriding the default values:
 
+
{{hc|/etc/sensors.d/HP_Z600|<nowiki>
Create {{ic|/etc/sensors.d/cores.conf}} wherein the new definitions are defined based on the output of step 1:
+
 
+
{{hc|/etc/sensors.d/cores.conf|<nowiki>
+
 
chip "coretemp-isa-0000"
 
chip "coretemp-isa-0000"
 
+
  label temp2 "Core 0"
    label temp2 "Core 0"
+
  label temp3 "Core 1"
    label temp3 "Core 1"
+
  label temp11 "Core 2"
    label temp11 "Core 2"
+
  label temp12 "Core 3"
    label temp12 "Core 3"
+
  
 
chip "coretemp-isa-0004"
 
chip "coretemp-isa-0004"
 +
  label temp2 "Core 4"
 +
  label temp3 "Core 5"
 +
  label temp11 "Core 6"
 +
  label temp12 "Core 7"</nowiki>}}
  
    label temp2 "Core 4"
+
Now invoking {{ic|sensors}} shows the adjust values:
    label temp3 "Core 5"
+
    label temp11 "Core 6"
+
    label temp12 "Core 7"</nowiki>}}
+
 
+
Problem solved.  Output after completing these steps:
+
 
+
 
{{hc|$ sensors|<nowiki>
 
{{hc|$ sensors|<nowiki>
 
coretemp-isa-0000
 
coretemp-isa-0000
Line 303: Line 352:
 
Core6:        +59.0°C  (high = +85.0°C, crit = +95.0°C)
 
Core6:        +59.0°C  (high = +85.0°C, crit = +95.0°C)
 
Core7:        +60.0°C  (high = +85.0°C, crit = +95.0°C)
 
Core7:        +60.0°C  (high = +85.0°C, crit = +95.0°C)
 
+
...
smsc47b397-isa-0480
+
Adapter: ISA adapter
+
fan1:        1734 RPM
+
fan2:        1726 RPM
+
fan3:        1222 RPM
+
fan4:        2827 RPM
+
temp1:        +45.0°C 
+
temp2:        +37.0°C 
+
temp3:        +23.0°C 
+
temp4:      -128.0°C 
+
 
</nowiki>}}
 
</nowiki>}}
  
=== Sensors not working since Linux 2.6.31 ===
+
=== Automatic lm_sensors Deployment ===
A change in version 2.6.31 has made some sensors stop working.  See [http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31 this FAQ entry] for a detailed explanation and for some example errors.  To fix sensors, add the following [[kernel parameters]]:
+
If users wishing to deploy lm_sensors on multiple machines can use either of the following:
acpi_enforce_resources=lax
+
{{Warning|In some situations, this may be dangerous. Consult the FAQ for details.}}
+
  
Note that in most cases the information is still accessible via other modules (e.g. via ACPI modules) for the hardware in questionMany utilities and monitors (e.g. {{ic|/usr/bin/sensors}}) can gather information from either source.  Where possible, this is the preferred solution.
+
1. Accept defaults to questions:
 +
  # sensors-detect --auto
  
===K10Temp Module===
+
2. Override defaults and answer YES to all questions:
 +
  # yes | sensors-detect
 +
 
 +
== Troubleshooting ==
 +
 
 +
=== K10Temp Module ===
  
 
Some K10 processors have issues with their temperature sensor.  From the kernel documentation ({{ic|linux-&lt;version&gt;/Documentation/hwmon/k10temp}}):
 
Some K10 processors have issues with their temperature sensor.  From the kernel documentation ({{ic|linux-&lt;version&gt;/Documentation/hwmon/k10temp}}):
:''All these processors have a sensor, but on those for Socket F or AM2+, the sensor may return inconsistent values (erratum 319).  The driver will refuse to load on these revisions unless you specify the {{ic|1=force=1}} module parameter.''
 
  
:''Due to technical reasons, the driver can detect only the mainboard's socket type, not the processor's actual capabilities.  Therefore, if you are using an AM3 processor on an AM2+ mainboard, you can safely use the {{ic|1=force=1}} parameter.''
+
:''All these processors have a sensor, but on those for Socket F or AM2+, the sensor may return inconsistent values (erratum 319).  The driver will refuse to load on these revisions unless users specify the {{ic|1=force=1}} module parameter.''
 +
 
 +
:''Due to technical reasons, the driver can detect only the mainboard's socket type, not the processor's actual capabilities.  Therefore, users of an AM3 processor on an AM2+ mainboard, can safely use the {{ic|1=force=1}} parameter.''
 +
 
 +
On affected machines the module will report "unreliable CPU thermal sensor; monitoring disabled". Users which to force it can:
  
On affected machines the module will report "unreliable CPU thermal sensor; monitoring disabled". If you still want to use the module you can:
 
 
  # rmmod k10temp
 
  # rmmod k10temp
 
  # modprobe k10temp force=1
 
  # modprobe k10temp force=1
Confirm with [[Lm_sensors#Testing your lm_sensors]] that the sensor is in fact valid and reliable. If it is, you can edit {{ic|/etc/modprobe.d/k10temp.conf}} and add:
+
 
 +
Confirm that the sensor is in fact valid and reliable. If it is, can edit {{ic|/etc/modprobe.d/k10temp.conf}} and add:
 +
 
 
  options k10temp force=1
 
  options k10temp force=1
 +
 
This will allow the module to load at boot.
 
This will allow the module to load at boot.
  
==See also==
+
=== Sensors not working since Linux 2.6.31 ===
*[[hddtemp]] - Software to read temperatures of hard drives.
+
{{Out of date|kernel 2.6 references|section=kernel 2.6 workaround}}
*[[monitorix]] - Monitorix is a free, open source, lightweight system monitoring tool designed to monitor as many services and system resources as possible.
+
A change in version 2.6.31 has made some sensors stop working.  See [http://www.lm-sensors.org/wiki/FAQ/Chapter3#Mysensorshavestoppedworkinginkernel2.6.31 this FAQ entry] for a detailed explanation and for some example errors.  To fix sensors, add the following [[kernel parameters]]:
 +
 
 +
acpi_enforce_resources=lax
 +
 
 +
{{Warning|In some situations, this may be dangerous. Consult the FAQ for details.}}
 +
 
 +
Note that in most cases the information is still accessible via other modules (e.g. via ACPI modules) for the hardware in question.  Many utilities and monitors (e.g. {{ic|/usr/bin/sensors}}) can gather information from either source.  Where possible, this is the preferred solution.
 +
 
 +
=== Gigabyte GA-J1900N-D3V ===
 +
 
 +
The motherboard use the ITE IT8620E chip (useful also to read voltages, mainboard temp, fan speed).
 +
As of October 2014, lm_sensors has no driver support for chip ITE IT8620E [http://www.lm-sensors.org/wiki/Devices] [http://comments.gmane.org/gmane.linux.drivers.sensors/35168].
 +
lm_sensors developers had a report that the chip is somewhat compatible with the IT8728F for the hardware monitoring part.
 +
 
 +
You can load the module at runtime with modprobe:
 +
 
 +
$ modprobe it87 force_id=0x8728
 +
 
 +
Or you can [[Kernel modules#Loading|load the module]] during boot process by creating the following two files:
 +
 
 +
{{hc|/etc/modules-load.d/it87.conf|2=
 +
it87
 +
}}
 +
 
 +
{{hc|/etc/modprobe.d/it87.conf|2=
 +
options it87 force_id=0x8603
 +
}}
 +
 
 +
Once the module is loaded you can use the ''sensors'' tool to probe the chip.
 +
 
 +
Now you can also use [[fancontrol]] to control the speedsteps of your case fan.
 +
 
 +
=== Laptop Screen issues after running sensors-detect ===
 +
This is caused by lm-sensors messing with the Vcom values of the screen while probing for sensors.
 +
It has been discussed and solved at the forums already: https://bbs.archlinux.org/viewtopic.php?id=193048
 +
However, make sure to read through the thread carefully before running any of the suggested commands.

Latest revision as of 23:25, 10 June 2016

lm_sensors (Linux monitoring sensors) is a free and open-source application that provides tools and drivers for monitoring temperatures, voltage, and fans. This document explains how to install, configure, and use lm_sensors.

Installation

Install the lm_sensors package.

Note: More documentation is at the GitHub repository. In the future these may be installed, see FS#48354.

Setup

Use sensors-detect as root to detect and generate a list of kernel modules:

Warning: Do not use anything other than the default options (by just hitting Enter), unless you know exactly what you are doing. See #Laptop Screen issues after running sensors-detect.
# sensors-detect

It will ask to probe for various hardware. The "safe" answers are the defaults, so just hitting Enter to all the questions will generally not cause any problems. This will create the /etc/conf.d/lm_sensors configuration file which is used by lm_sensors.service to automatically load kernel modules on boot.

When the detection is finished, a summary of the probes is presented.

Example:

# sensors-detect
This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No

...

Now follows a summary of the probes I have just done.
Just press ENTER to continue: 

Driver `coretemp':
  * Chip `Intel digital thermal sensor' (confidence: 9)

Driver `lm90':
  * Bus `SMBus nForce2 adapter at 4d00'
    Busdriver `i2c_nforce2', I2C address 0x4c
    Chip `Winbond W83L771AWG/ASG' (confidence: 6)

Do you want to overwrite /etc/conf.d/lm_sensors? (YES/no): 
ln -s '/usr/lib/systemd/system/lm_sensors.service' '/etc/systemd/system/multi-user.target.wants/lm_sensors.service'
Unloading i2c-dev... OK
Unloading cpuid... OK
Note: A systemd service is automatically enabled if users answer YES when asked about generating /etc/conf.d/lm_sensors. Answering YES also automatically starts the service.

Running sensors

Example running sensors:

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +35.0°C  (crit = +105.0°C)
Core 1:       +32.0°C  (crit = +105.0°C)

w83l771-i2c-0-4c
Adapter: SMBus nForce2 adapter at 4d00
temp1:        +28.0°C  (low  = -40.0°C, high = +70.0°C)
                       (crit = +85.0°C, hyst = +75.0°C)
temp2:        +37.4°C  (low  = -40.0°C, high = +70.0°C)
                       (crit = +110.0°C, hyst = +100.0°C)

Reading SPD values from memory modules (optional)

To read the SPD timing values from memory modules, install the i2c-tools package. Once installed, load the eeprom kernel module.

# modprobe eeprom

Finally, view memory information with decode-dimms.

Here is partial output from one machine:

# decode-dimms
Memory Serial Presence Detect Decoder
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,
Jean Delvare, Trent Piepho and others


Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0050
Guessing DIMM is in                             bank 1

---=== SPD EEPROM Information ===---
EEPROM CRC of bytes 0-116                       OK (0x583F)
# of bytes written to SDRAM EEPROM              176
Total number of bytes in EEPROM                 512
Fundamental Memory type                         DDR3 SDRAM
Module Type                                     UDIMM

---=== Memory Characteristics ===---
Fine time base                                  2.500 ps
Medium time base                                0.125 ns
Maximum module speed                            1066MHz (PC3-8533)
Size                                            2048 MB
Banks x Rows x Columns x Bits                   8 x 14 x 10 x 64
Ranks                                           2
SDRAM Device Width                              8 bits
tCL-tRCD-tRP-tRAS                               7-7-7-33
Supported CAS Latencies (tCL)                   8T, 7T, 6T, 5T

---=== Timing Parameters ===---
Minimum Write Recovery time (tWR)               15.000 ns
Minimum Row Active to Row Active Delay (tRRD)   7.500 ns
Minimum Active to Auto-Refresh Delay (tRC)      49.500 ns
Minimum Recovery Delay (tRFC)                   110.000 ns
Minimum Write to Read CMD Delay (tWTR)          7.500 ns
Minimum Read to Pre-charge CMD Delay (tRTP)     7.500 ns
Minimum Four Activate Window Delay (tFAW)       30.000 ns

---=== Optional Features ===---
Operable voltages                               1.5V
RZQ/6 supported?                                Yes
RZQ/7 supported?                                Yes
DLL-Off Mode supported?                         No
Operating temperature range                     0-85C
Refresh Rate in extended temp range             1X
Auto Self-Refresh?                              Yes
On-Die Thermal Sensor readout?                  No
Partial Array Self-Refresh?                     No
Thermal Sensor Accuracy                         Not implemented
SDRAM Device Type                               Standard Monolithic

---=== Physical Characteristics ===---
Module Height (mm)                              15
Module Thickness (mm)                           1 front, 1 back
Module Width (mm)                               133.5
Module Reference Card                           B

---=== Manufacturer Data ===---
Module Manufacturer                             Invalid
Manufacturing Location Code                     0x02
Part Number                                     OCZ3G1600LV2G     

...

Using Sensor Data

Graphical Front-ends

There are a variety of front-ends for sensors data.

  • conky - Conky is an advanced, highly configurable system monitor for X based on torsmo
  • xsensors - X11 interface to lm_sensors
  • psensorAUR - GTK+ application for monitoring hardware sensors, including temperatures and fan speeds. Monitors motherboard and CPU (using lm-sensors), Nvidia GPUs (using XNVCtrl), and harddisks (using hddtemp or libatasmart).

For specific Desktop environments:

sensord

There is an optional daemon called sensord (included with the lm_sensors package) which can log data to a round robin database (rrd) and later visualize graphically. See the sensord man page for details.

Tips and Tricks

Adjusting Values

In some cases, the data displayed might be incorrect or users may wish to rename the output. Use cases include:

  • Incorrect temperature values due to a wrong offset (i.e. temps are reported 20 °C higher then actual).
  • Users wish to rename the output of some sensors.
  • The cores might be displayed in an incorrect order.

All of the above (and more) can be adjusted by overriding the package provides settings in /etc/sensors3.conf by creating /etc/sensors.d/foo wherein any number of tweaks will override the default values. It is recommended to rename 'foo' to the motherboard brand and model but this naming nomenclature is optional.

Note: Do not edit /etc/sensors3.conf directly since package updates will overwrite any changes thus losing them.

Example 1. Adjusting Temperature Offsets

This is a real example on a Zotac ION-ITX-A-U motherboard. The coretemp values are off by 20 °C (too high) and are adjusted down to Intel specs.

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +57.0°C  (crit = +125.0°C)
Core 1:       +55.0°C  (crit = +125.0°C)
...

Run sensors with the -u switch to see what options are available for each physical chip (raw mode):

$ sensors -u
coretemp-isa-0000
Adapter: ISA adapter
Core 0:
  temp2_input: 57.000
  temp2_crit: 125.000
  temp2_crit_alarm: 0.000
Core 1:
  temp3_input: 55.000
  temp3_crit: 125.000
  temp3_crit_alarm: 0.000
...

Create the following file overriding the default values:

/etc/sensors.d/Zotac-IONITX-A-U
chip "coretemp-isa-0000"
  label temp2 "Core 0"
  compute temp2 @-20,@-20

  label temp3 "Core 1"
  compute temp3 @-20,@-20

Now invoking sensors shows the adjust values:

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +37.0°C  (crit = +105.0°C)
Core 1:       +35.0°C  (crit = +105.0°C)
...

Example 2. Renaming Labels

This is a real example on an Asus A7M266. The user wishes more verbose names for the temperature labels 'temp1' and 'temp2':

$ sensors
as99127f-i2c-0-2d
Adapter: SMBus Via Pro adapter at e800
...
temp1:        +35.0°C  (high =  +0.0°C, hyst = -128.0°C)
temp2:        +47.5°C  (high = +100.0°C, hyst = +75.0°C)
...

Create the following file to override the default values:

/etc/sensors.d/Asus_A7M266
chip "as99127f-*"
  label temp1 "Mobo Temp"
  label temp2 "CPU0 Temp"

Now invoking sensors shows the adjust values:

$ sensors
as99127f-i2c-0-2d
Adapter: SMBus Via Pro adapter at e800
...
Mobo Temp:        +35.0°C  (high =  +0.0°C, hyst = -128.0°C)
CPU0 Temp:        +47.5°C  (high = +100.0°C, hyst = +75.0°C)
...

Example 3. Renumbering Cores for Multi-CPU Systems

This is a real example on an HP Z600 workstation with dual Xeons. The actual numbering of physical cores is incorrect: numbered 0, 1, 9, 10 which is repeated into the second CPU. Most users expect the core temperatures to report out in sequential order, i.e. 0,1,2,3,4,5,6,7.

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +65.0°C  (high = +85.0°C, crit = +95.0°C)
Core 1:       +65.0°C  (high = +85.0°C, crit = +95.0°C)
Core 9:       +66.0°C  (high = +85.0°C, crit = +95.0°C)
Core 10:      +66.0°C  (high = +85.0°C, crit = +95.0°C)

coretemp-isa-0004
Adapter: ISA adapter
Core 0:       +54.0°C  (high = +85.0°C, crit = +95.0°C)
Core 1:       +56.0°C  (high = +85.0°C, crit = +95.0°C)
Core 9:       +60.0°C  (high = +85.0°C, crit = +95.0°C)
Core 10:      +61.0°C  (high = +85.0°C, crit = +95.0°C)
...

Again, run sensors with the -u switch to see what options are available for each physical chip:

$ sensors -u coretemp-isa-0000
coretemp-isa-0000
Adapter: ISA adapter
Core 0:
  temp2_input: 61.000
  temp2_max: 85.000
  temp2_crit: 95.000
  temp2_crit_alarm: 0.000
Core 1:
  temp3_input: 61.000
  temp3_max: 85.000
  temp3_crit: 95.000
  temp3_crit_alarm: 0.000
Core 9:
  temp11_input: 62.000
  temp11_max: 85.000
  temp11_crit: 95.000
Core 10:
  temp12_input: 63.000
  temp12_max: 85.000
  temp12_crit: 95.000
$ sensors -u coretemp-isa-0004
coretemp-isa-0004
Adapter: ISA adapter
Core 0:
  temp2_input: 53.000
  temp2_max: 85.000
  temp2_crit: 95.000
  temp2_crit_alarm: 0.000
Core 1:
  temp3_input: 54.000
  temp3_max: 85.000
  temp3_crit: 95.000
  temp3_crit_alarm: 0.000
Core 9:
  temp11_input: 59.000
  temp11_max: 85.000
  temp11_crit: 95.000
Core 10:
  temp12_input: 59.000
  temp12_max: 85.000
  temp12_crit: 95.000
...

Create the following file overriding the default values:

/etc/sensors.d/HP_Z600
chip "coretemp-isa-0000"
  label temp2 "Core 0"
  label temp3 "Core 1"
  label temp11 "Core 2"
  label temp12 "Core 3"

chip "coretemp-isa-0004"
  label temp2 "Core 4"
  label temp3 "Core 5"
  label temp11 "Core 6"
  label temp12 "Core 7"

Now invoking sensors shows the adjust values:

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Core0:        +64.0°C  (high = +85.0°C, crit = +95.0°C)
Core1:        +63.0°C  (high = +85.0°C, crit = +95.0°C)
Core2:        +65.0°C  (high = +85.0°C, crit = +95.0°C)
Core3:        +66.0°C  (high = +85.0°C, crit = +95.0°C)

coretemp-isa-0004
Adapter: ISA adapter
Core4:        +53.0°C  (high = +85.0°C, crit = +95.0°C)
Core5:        +54.0°C  (high = +85.0°C, crit = +95.0°C)
Core6:        +59.0°C  (high = +85.0°C, crit = +95.0°C)
Core7:        +60.0°C  (high = +85.0°C, crit = +95.0°C)
...

Automatic lm_sensors Deployment

If users wishing to deploy lm_sensors on multiple machines can use either of the following:

1. Accept defaults to questions:

# sensors-detect --auto

2. Override defaults and answer YES to all questions:

 # yes | sensors-detect

Troubleshooting

K10Temp Module

Some K10 processors have issues with their temperature sensor. From the kernel documentation (linux-<version>/Documentation/hwmon/k10temp):

All these processors have a sensor, but on those for Socket F or AM2+, the sensor may return inconsistent values (erratum 319). The driver will refuse to load on these revisions unless users specify the force=1 module parameter.
Due to technical reasons, the driver can detect only the mainboard's socket type, not the processor's actual capabilities. Therefore, users of an AM3 processor on an AM2+ mainboard, can safely use the force=1 parameter.

On affected machines the module will report "unreliable CPU thermal sensor; monitoring disabled". Users which to force it can:

# rmmod k10temp
# modprobe k10temp force=1

Confirm that the sensor is in fact valid and reliable. If it is, can edit /etc/modprobe.d/k10temp.conf and add:

options k10temp force=1

This will allow the module to load at boot.

Sensors not working since Linux 2.6.31

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: kernel 2.6 references (Discuss in Talk:Lm sensors#kernel 2.6 workaround)

A change in version 2.6.31 has made some sensors stop working. See this FAQ entry for a detailed explanation and for some example errors. To fix sensors, add the following kernel parameters:

acpi_enforce_resources=lax
Warning: In some situations, this may be dangerous. Consult the FAQ for details.

Note that in most cases the information is still accessible via other modules (e.g. via ACPI modules) for the hardware in question. Many utilities and monitors (e.g. /usr/bin/sensors) can gather information from either source. Where possible, this is the preferred solution.

Gigabyte GA-J1900N-D3V

The motherboard use the ITE IT8620E chip (useful also to read voltages, mainboard temp, fan speed). As of October 2014, lm_sensors has no driver support for chip ITE IT8620E [1] [2]. lm_sensors developers had a report that the chip is somewhat compatible with the IT8728F for the hardware monitoring part.

You can load the module at runtime with modprobe:

$ modprobe it87 force_id=0x8728

Or you can load the module during boot process by creating the following two files:

/etc/modules-load.d/it87.conf
it87
/etc/modprobe.d/it87.conf
options it87 force_id=0x8603

Once the module is loaded you can use the sensors tool to probe the chip.

Now you can also use fancontrol to control the speedsteps of your case fan.

Laptop Screen issues after running sensors-detect

This is caused by lm-sensors messing with the Vcom values of the screen while probing for sensors. It has been discussed and solved at the forums already: https://bbs.archlinux.org/viewtopic.php?id=193048 However, make sure to read through the thread carefully before running any of the suggested commands.