lm_sensors

To find the temperature sensors of DIMMs, install the package. Once installed, load the kernel module.

# modprobe i2c_dev

To show all the columns, use i2cdetect as root:

Otherwise, its output will appear as follows:

i2c-2	unknown    	SMBus PIIX4 adapter port 2 at 0b00	N/A
i2c-2	unknown    	SMBus PIIX4 adapter port 1 at 0b20	N/A
i2c-0	unknown    	SMBus PIIX4 adapter port 0 at 0b00	N/A

In my system, RAM sticks connected to the bus is SMBus 0. The i2cdetect command will show the devices that connected to the bus. The argument means use i2c-0 smbus. You can check other buses if needed.

RAM SPD's are start from address 0x50 and RAM temp sensors start from 0x18 at same bus. In my system, there are 2 DIMMs available. So address of 0x18 and 0x19 are DIMMs temp sensors.

After found this info, to read temperatures of RAM sticks, we need kernel module loaded. After that you need to tell to module that which addresses are need to used. This process consists of writing and to smbus_path. For example:

# modprobe jc42
# echo jc42 0x18 > /sys/bus/i2c/devices/i2c-0/new_device
# echo jc42 0x19 > /sys/bus/i2c/devices/i2c-0/new_device

After that your ram sticks temperature will be visible on command:

jc42-i2c-0-19
Adapter: SMBus PIIX4 adapter port 0 at 0b00
temp1:        +50.7°C  (low  =  +0.0°C)                  ALARM (HIGH, CRIT)
                       (high =  +0.0°C, hyst =  +0.0°C)
                       (crit =  +0.0°C, hyst =  +0.0°C)

jc42-i2c-0-18
Adapter: SMBus PIIX4 adapter port 0 at 0b00
temp1:        +51.8°C  (low  =  +0.0°C)                  ALARM (HIGH, CRIT)
                       (high =  +0.0°C, hyst =  +0.0°C)
                       (crit =  +0.0°C, hyst =  +0.0°C)

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

# modprobe eeprom

Finally, view memory information with .

Here is partial output from one machine:

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

For specific Desktop environments:

• MATE Sensors Applet — Display readings from hardware sensors in your MATE panel.

https://github.com/mate-desktop/mate-sensors-applet || mate-sensors-applet

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 man page for details.

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 than 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 by creating 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.

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.

Run with the switch to see what options are available for each physical chip (raw mode). If some of the raw labels you are presented seem not to be configurable, look at the directory tree. Each device mentioned there has a file, which can be used to match the device it is referring to. And then try the labels referred to by that directory.

$ 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:

Now invoking shows the adjust values:

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

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 shows the adjust values:

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.

Again, run with the 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

Create the following file overriding the default values:

Now invoking shows the adjust values:

Users wishing to deploy lm_sensors on multiple machines can use the following to accept the defaults to all questions:

# sensors-detect --auto

Since kernel 5.6 the module will report SATA/SAS temperature through hwmon, but does not automatically detect this so the module must be manually loaded.

# modprobe drivetemp

You should now see entries similar to this in your output:

You can now load the module at boot. Alternatively, manually add it to the line of /etc/conf.d/lm-sensors. Do note it will not be added automatically when will be allowed to write this file again.

Some K10 processors have issues with their temperature sensor. See the k10temp documentation for more information.

On affected machines the module will report "unreliable CPU thermal sensor; monitoring disabled". To force monitoring anyway, you can run the following:

# rmmod k10temp
# modprobe k10temp force=1

Confirm that the sensor is in fact valid and reliable. If it is, can edit and add:

options k10temp force=1

This will allow the module to load at boot.

These motherboards use a IT8655E chip, which is not supported by the it87 kernel driver, as of Nov 2020 . However, it is supported by the upstream version of the kernel driver . The DKMS variant is contained in it87-dkms-git^AUR.

Some recent Asus motherboards use a ITE IT8665E chip, accessing the temperature, fan and voltage sensors may require the module. It is part of the mainline kernel since 5.17: load the kernel module which uses the UEFI interface and may require a BIOS update on some boards .

Alternatively, the module reads the values from the chip directly, install it87-dkms-git^AUR and load the kernel module.

With some recent Asus motherboards, fan and voltage sensor access may require the kernel module to be loaded.

You may also need to add the following kernel parameter:

acpi_enforce_resources=lax

See https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information.

Note: Starting with Kernel 5.16 , the above kernel parameter is no longer be required for most boards and should be avoided.

The STX board of the Deskmini H470 uses a NCT6683 chip, for accessing the temperature, fan and voltage sensors the loading of module is required.

For proper values of the module have a module config file created:

Some Gigabyte motherboards use the ITE IT8686E, ITE8689 (for B560) or ITE8689E (for Z690) chip, which is not supported by the it87 kernel driver, as of May 2019 . However, it is supported by the upstream version of the kernel driver . The DKMS variant is contained in it87-dkms-git^AUR. As with #Asus H97/Z97/Z170/Z370i/X570/B550 motherboards, a kernel parameter is required before attempting to install the module:

acpi_enforce_resources=lax

Furthermore, supply the id of the chip when loading the module as follows:

# modprobe it87 force_id=0x8686
or
# modprobe it87 force_id=0x8689  # for B560
# modprobe it87 force_id=0x8628  # for Z690

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

For Z690

For others

Once the module is loaded you can use the sensors tool to probe the chip. Now you can also use fancontrol to control the speed step of your case fan.

Optionally installation of zenpower3-dkms^AUR may allow greater fine tuning of the motherboard's cooling system. However, it does disable the default k10temp module.

This motherboard uses 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 . lm_sensors developers had a report that the chip is somewhat compatible with the IT8728F for the hardware monitoring part. However, as of August 2016, lists the IT8620E as supported.

You can load the module at runtime with modprobe:

$ modprobe it87 force_id=0x8728

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

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

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.

There is currently a bug in the way the kernel handles reading the i2c bus on AMD Navi 2 GPUs. The bus currently can only be used with EEPROMs and trying to use it with other devices will cause it to fail. This can cause crashes, black screens, and even cause the card to behave oddly like unable to switch power states. Its currently advised not to scan the i2c bus if you have a Navi 2 based card. You can read more here: https://gitlab.freedesktop.org/drm/amd/-/issues/1470