Jump to content
From ArchWiki

Related articles

- Fan speed control
- hddtemp
- I2C
- monitorix

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.

## Configuration

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)

### Adding DIMM temperature sensors

To find the temperature sensors of DIMMs, install the i2c-tools package. Once installed, load the `i2c-dev` kernel module.

    # modprobe i2c_dev

To show all the columns, use i2cdetect as root:

    # i2cdetect -l

    i2c-2	smbus     	SMBus PIIX4 adapter port 2 at 0b00	SMBus adapter
    i2c-2	smbus     	SMBus PIIX4 adapter port 1 at 0b20	SMBus adapter
    i2c-0	smbus     	SMBus PIIX4 adapter port 0 at 0b00	SMBus adapter

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 the following example, RAM sticks are connected to the bus `SMBus 0`. The i2cdetect command will show the devices that are connected to the bus. The `-y 0` argument uses the `i2c-0` smbus. Check other buses if needed.

    # i2cdetect -y 0

    0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
    00:                         -- -- -- -- 0c -- -- --
    10: 10 -- -- -- -- -- -- -- 18 19 -- -- -- -- -- --
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    30: -- -- -- -- -- -- 36 -- -- -- -- -- -- -- -- --
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 4f
    50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- 77

RAM SPD's (serial presence detect) start from address `0x50` and RAM temperature sensors start from `0x18` at same bus. In this example, there are 2 DIMMs available. The address `0x18` and `0x19` are the DIMMs temperature sensors.

To read the temperatures of RAM sticks, we need the `jc42` kernel module loaded. You need to tell the module which addresses to use. This process consists of writing the `module_name` and `address` 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:

    $ sensors

    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)

### 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 `at24` or `eeprom` (deprecated) kernel module.

    # modprobe at24

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.

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

  https://wpitchoune.net/psensor/ || psensor

- xsensors — X11 interface to lm_sensors.

  https://github.com/Mystro256/xsensors || xsensors

- Netdata — Web based system monitor (netdata).

  https://github.com/netdata/netdata || netdata

- CoolerControl — A program to monitor and control your cooling devices.

  https://gitlab.com/coolercontrol/coolercontrol || coolercontrolAUR

For specific Desktop environments:

- Freon (GNOME Shell extension) — Extension for displaying CPU temperature, disk temperature, video card temperature , voltage and fan RPM in GNOME Shell.

  https://github.com/UshakovVasilii/gnome-shell-extension-freon || gnome-shell-extension-freonAUR

- GNOME Sensors Applet — Applet for the GNOME Panel to display readings from hardware sensors, including CPU temperature, fan speeds and voltage readings.

  http://sensors-applet.sourceforge.net/ || sensors-applet

- lm-sensors (LXPanel plugin) — Monitor temperature/voltages/fan speeds in LXDE through lm-sensors.

  https://danamlund.dk/sensors_lxpanel_plugin/ || sensors-lxpanel-pluginAUR

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

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

- Sensors (Xfce4 panel plugin) — Hardware sensors plugin for the Xfce panel.

  https://goodies.xfce.org/projects/panel-plugins/xfce4-sensors-plugin || xfce4-sensors-plugin

- Thermal Monitor (Plasma 5 applet) — KDE Plasma applet for monitoring CPU, GPU and other available temperature sensors.

  https://gitlab.com/agurenko/plasma-applet-thermal-monitor || plasma5-applets-thermal-monitor

### 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(8) 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 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 provided 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.

Custom configuration files for a number of motherboards can be found in the configs directory of the lm-sensors package and be used as templates.

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). If some of the raw labels you are presented seem not to be configurable, look at the `/sys/class/hwmon` directory tree. Each device mentioned there has a `name` 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:

    /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

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

    # sensors-detect --auto

### S.M.A.R.T. drive temperature

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

    # modprobe drivetemp

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

    sensors

    drivetemp-scsi-1-0
    Adapter: SCSI adapter
    temp1:        +33.0°C

    drivetemp-scsi-2-0
    Adapter: SCSI adapter
    temp1:        +32.0°C  (low  =  +0.0°C, high = +70.0°C)
                           (crit low =  +0.0°C, crit = +70.0°C)
                           (lowest = +29.0°C, highest = +41.0°C)

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

### Persistent device names

Many pieces of software expect sensor devices to stay put in `/sys/class/hwmon/hwmonX`, but more often than not, they don't on systems with more than 1-2 devices providing a hwmon interface. Software should probably parse the `hwmon?/name` or use lmsensors libraries, but more often than not, they sadly don't. Some software (example: Monitorix or certain modules of it, namely amdgpu) expect persistent names somewhere else.

Hence, the following kind of udev rules might be useful. Not all software can use them (for example, KDE system monitor - which sadly, makes these software almost useless on many systems). For many cases, simply matching the hwmon subsystem and a suitable name in the udev rule should be enough - but not always! See Udev page for more information on writing rules.

One can not rename or symlink under `/sys` hieraerchy. A `SYMLINK+=` -statement will also not work. Hence, we need to use the `RUN+=` statement (note, the symlink does not need to be under `/dev` as in this example - there is no standard nor a good place for them).

    /etc/udev/rules.d/99-persistent-hwmon-names.rules

    # my motherboard sensor chip:
    ACTION=="add", SUBSYSTEM=="hwmon", ATTRS{name}=="nct6687", RUN+="/bin/sh -c 'ln -s /sys$devpath /dev/nct6678'"
    # an USB device providing sensors:
    ACTION=="add", SUBSYSTEM=="hwmon", ATTRS{name}=="corsaircpro", RUN+="/bin/sh -c 'ln -s /sys$devpath /dev/corsaircpro'"
    # my GPU:
    ACTION=="add", SUBSYSTEM=="hwmon", ATTRS{vendor}=="0x1002", ATTRS{device}=="0x73bf", RUN+="/bin/sh -c 'ln -s /sys$devpath /dev/rx6900xt'"

## Troubleshooting

### K10Temp module

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 `/etc/modprobe.d/k10temp.conf` and add:

    options k10temp force=1

This will allow the module to load at boot.

### Asus B450M-A/A320M-K/A320M-K-BR motherboards

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

### Asus B450/X399/X470 motherboards with AM4 Socket

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

Alternatively, the `it87` module reads the values from the chip directly, install it87-dkms-gitAUR and load the `it87` kernel module.

### Asus H97/Z97/Z170/Z370i/X570/B550 motherboards

With some recent Asus motherboards, fan and voltage sensor access may require the `nct6775` 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 [4], the above kernel parameter is no longer be required for most boards and should be avoided.

### Asrock Deskmini H470

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

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

    /etc/modprobe.d/nct6683.conf

    options nct6683 force=1

### Gigabyte B250/Z370/B450M/B560M/B660M/Z690 motherboards

Some Gigabyte motherboards use the ITE IT8686E, ITE8689 (for B560 and B660M) or ITE8689E (for Z690) chip, which is not supported by the it87 kernel driver, as of May 2019 [5]. However, it is supported by the upstream version of the kernel driver [6]. The DKMS variant is contained in it87-dkms-gitAUR. 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:

    /etc/modules-load.d/it87.conf

    it87

For Z690

    /etc/modprobe.d/it87.conf

    options it87 force_id=0x8628

For others

    /etc/modprobe.d/it87.conf

    options it87 ignore_resource_conflict=1

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-dkmsAUR may allow greater fine tuning of the motherboard's cooling system. However, it does disable the default k10temp module.

### Gigabyte GA-J1900N-D3V

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 [7] [8]. 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, [9] 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/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.

### i2c bus errors on AMD Navi 2 GPUs

This article or section is being considered for removal.

Reason: the bug has been fixed a year and a half ago.[10] (Discuss in Talk:Lm sensors)

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

Categories:

- System monitors
- CPU

Hidden category:

- Sections flagged with Template:Remove