Sensors - cpu_fan = 0 RPM (and no service script generated)

Moun · 06-20-2020, 01:48 PM

I get a similar situation described in a previous thread.

Before submitting an issue to the project GitHub page, I prefer confirm this is not an issue related to my installation. Installed package is the official lm_sensors-3.4.0-x86_64-1.

Running sensors-detect leads me to this result:

Code:

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 `nct6775':
  * ISA bus, address 0x290
    Chip `Nuvoton NCT5532D/NCT6779D Super IO Sensors' (confidence: 9)

Do you want to overwrite /etc/sysconfig/lm_sensors? (YES/no): yes
Copy prog/init/lm_sensors.init to /etc/init.d/lm_sensors
for initialization at boot time.
You should now start the lm_sensors service to load the required
kernel modules.

/etc/sysconfig/lm_sensors contains :

Code:

# [...]
# This file is sourced by /etc/init.d/
lm_sensors and defines the modules toWMON_MODULES="coretemp nct6775"

However, I didn't find any lm_sensors.init file with the command below:

Code:

find /{bin,dev,etc,lib,lib64,root,run,sbin,srv,sys,tmp,usr,var} -iname lm_sensors.init

After reading sensors-detect, which is actually a Perl script, it seems this message is displayed if the script failed to find /bin/systemctl.

It may be the expected situation with Slackware. By the way, I added a line to load nct6775 in /etc/rc.d/rc.local:

Code:

modprobe nct6775

Once the module loaded a wild hwmon2 appears (I wonder why I have an eeepc-wmi entry, it's a desktop computer):

Code:

/sys/class/hwmon/hwmon0 -> ../../devices/platform/eeepc-wmi/hwmon/hwmon0/
/sys/class/hwmon/hwmon1 -> ../../devices/platform/coretemp.0/hwmon/hwmon1/
/sys/class/hwmon/hwmon2 -> ../../devices/platform/nct6775.656/hwmon/hwmon2/

Only hwmon0 and hwmon2 have fan informations. The alias hwmon0 seems to reference the cpu fan:

Code:

/sys/class/hwmon/hwmon0/fan1_input
/sys/class/hwmon/hwmon0/fan1_label (contains "cpu_fan")

The alias hwmon2 references 5 fans without labels.

But what bugs me is that the hwmon0/fan1_input file shows 0 RPM, among hwmon2/fan[4-5]_input ones, but I assume it's because those fans are not actually plugged for them.

Below summary outputted by inxi and sensors shows the same results, and several others fans (I only see 3 fans in my computer case).

inxi:

Code:

~$ inxi -MCs
Machine:   Type: Desktop Mobo: ASUSTeK model: P8Z77-V LX v: Rev X.0x serial: 120700329403428 BIOS: American Megatrends v: 0610 
           date: 05/08/2012 
CPU:       Topology: Quad Core model: Intel Core i5-3570K bits: 64 type: MCP L2 cache: 6144 KiB 
           Speed: 1644 MHz min/max: 1600/3800 MHz Core speeds (MHz): 1: 1694 2: 1897 3: 1705 4: 1604 
Sensors:   System Temperatures: cpu: 42.0 C mobo: N/A 
           Fan Speeds (RPM): cpu: 0 fan-1: 812 fan-2: 1319 fan-3: 736 fan-4: 0 fan-5: 0

sensors:

Code:

asus-isa-0000
Adapter: ISA adapter
cpu_fan:        0 RPM

coretemp-isa-0000
Adapter: ISA adapter
Physical id 0:  +54.0°C  (high = +85.0°C, crit = +105.0°C)
Core 0:         +55.0°C  (high = +85.0°C, crit = +105.0°C)
Core 1:         +54.0°C  (high = +85.0°C, crit = +105.0°C)
Core 2:         +53.0°C  (high = +85.0°C, crit = +105.0°C)
Core 3:         +51.0°C  (high = +85.0°C, crit = +105.0°C)

nct6779-isa-0290
Adapter: ISA adapter
Vcore:                  +0.92 V  (min =  +0.00 V, max =  +1.74 V)
in1:                    +1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
AVCC:                   +3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
+3.3V:                  +3.38 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                    +1.03 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                    +0.00 V  (min =  +0.00 V, max =  +0.00 V)
in6:                    +0.99 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
3VSB:                   +3.42 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
Vbat:                   +3.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                    +1.06 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                   +0.15 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                   +0.12 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                   +0.12 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                   +0.12 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                   +0.12 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                   869 RPM  (min =    0 RPM)
fan2:                  1383 RPM  (min =    0 RPM)
fan3:                   779 RPM  (min =    0 RPM)
fan4:                     0 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)
SYSTIN:                +119.0°C  (high =  +0.0°C, hyst =  +0.0°C)  sensor = thermistor
CPUTIN:                 +46.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
AUXTIN0:                +26.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM  sensor = thermistor
AUXTIN1:               +112.0°C    sensor = thermistor
AUXTIN2:               +111.0°C    sensor = thermistor
AUXTIN3:                +31.0°C    sensor = thermal diode
PECI Agent 0:           +46.0°C  
PCH_CHIP_CPU_MAX_TEMP:   +0.0°C  
PCH_CHIP_TEMP:           +0.0°C  
PCH_CPU_TEMP:            +0.0°C  
intrusion0:            ALARM
intrusion1:            ALARM
beep_enable:           disabled

Moun · 06-20-2020, 02:00 PM

UDPATE:
According to the BIOS, I have three working fans - one for the cpu, two for the computer case. There are listed by sensors under the hwmon2 alias:

fan1: 789 RPM (min = 0 RPM), a computer case fan
fan2: 1285 RPM (min = 0 RPM), the cpu fan
fan3: 718 RPM (min = 0 RPM), a computer case fan

So, it's like hwmon0 alias, eeepc-wmi isn't relevant. What is it and why do I have a cpu_fan entry here?

kingbeowulf · 06-20-2020, 02:37 PM

Maybe you have an ASUS laptop or motherboard and the module loaded:

Code:

# modinfo eeepc-wmi
filename:       /lib/modules/5.4.46/kernel/drivers/platform/x86/eeepc-wmi.ko
alias:          wmi:ABBC0F72-8EA1-11D1-00A0-C90629100000
license:        GPL
description:    Eee PC WMI Hotkey Driver
author:         Corentin Chary <corentin.chary@gmail.com>
depends:        asus-wmi
retpoline:      Y
intree:         Y
name:           eeepc_wmi
vermagic:       5.4.46 SMP mod_unload 
parm:           hotplug_wireless:Enable hotplug for wireless device. If your laptop needs that, please report to acpi4asus-user@lists.sourceforge.net. (bool)

and, just for example, https://github.com/lm-sensors/lm-sensors/issues/134
Depending on how your motherboard is wired, the fans may all be via the NCT sensor chip. The eeepc-wmi module has a few other hardware items besides fans such as support for ASUS laptop specialty keys. Often the kernel hardware driver will stick extra (or related) functionality into a module beyond the initial release and purpose. Perhaps hwmon0 has other information about your dektop beside fan0?

Moun · 06-20-2020, 06:56 PM

Thanks kingbeowulf for your answer.

I'm not sure to undersand your first sentence, but as I said, I have a desktop computer, with a case (chassis). My MB isn't designed for laptop.

I read this GitHub issue before posting my question, but unlike some people involved in I do not have a model handled by it87.

Quote:

Often the kernel hardware driver will stick extra (or related) functionality into a module beyond the initial release and purpose. Perhaps hwmon0 has other information about your dektop beside fan0?

Not many IMHO... Here is its content:

Code:

~$ tree /sys/class/hwmon/hwmon0
/sys/class/hwmon/hwmon0
├── device -> ../../../eeepc-wmi
├── fan1_input
├── fan1_label
├── name
├── power
│** ├── autosuspend_delay_ms
│** ├── control
│** ├── runtime_active_time
│** ├── runtime_status
│** └── runtime_suspended_time
├── pwm1_enable
├── subsystem -> ../../../../../class/hwmon
└── uevent

kingbeowulf · 06-22-2020, 10:48 PM

I don't think this is a lm-sensors issue. If the kernel thinks it needs to load eeepc-wmi, it will. It could also be possible that the kernel is mis-detecting your hardware and should be loading the asus-wmi. hwmon and various sensor drivers are part of the kernel. sensors-detect helps root out any that are not automatically detected. You can blacklist the eeepc-wmi module and see what happens. Its been a long while since I had a motherboard with a Z77 chipset. Also, just because your motherboard is not a laptop vesion, that does not mean "laptop" modules won't load. Those crazy hardware devs will often add functionality to an exiting module rather than write a new one. Asus could be using some hardware common to several motherboards.

It could also be possible that the kernel is mis-detecting your hardware and should be loading the asus-wmi. Either that, or you are booting the huge kernel with a host of built in modules that you do not need. lsmod won't show these typically but "ghost" system files can still be created.

Also, typically on Slackware, after running sensors-detect, you do not edit (or create) /etc/sysconfig/lmsensors. sensors-detect will list the sensor modules it finds. Some will already have been loaded at boot; others you put into /etc/rc.d/rc.local. For example, on my i7-6850K MSI X99S

Code:

$ cat rc.local
#!/bin/sh
#
# /etc/rc.d/rc.local:  Local system initialization script.
#
# Put any local startup commands in here.  Also, if you have
# anything that needs to be run at shutdown time you can
# make an /etc/rc.d/rc.local_shutdown script and put those
# commands in there.
#
# Chip drivers
#modprobe coretemp
modprobe nct6775
/usr/bin/sensors -s

coretemp is commented since it loads on boot. rc.local adds nct6775 and then runs 'sensors -s' to read the set statements in the default configuration file.

Moun · 06-23-2020, 10:02 AM

Thanks for the explanations.

I edited rc.local as said in a previous post, but I only added the modprobe nct6775 line, but not the sensors -s line, which reads the configuration file.

So I suppose that the /etc/init.d/lm_sensors, the startup script mentioned by sensors-detect (and not used with Slackware), if it was generated, would contain those two lines.

I think it's complete now. Thanks again.