I have a Toshiba NB510-108 netbook with Xubuntu 14.10 installed. Under Windows 7 Starter, temperature sensors show values up to 45 degrees Celsius. Under Xubuntu, they show values up to 55 degrees. I would like to use thermald to keep the temperature at 38 degrees. My thermal-conf.xml file only contains one sensor of type TSKN and two cooling devices of types rapl_controller and intel_powerclamp. sensors -u shows this user@user-TOSHIBA-NB510:~$ sensors -u acpitz-virtual-0 Adapter: Virtual device temp1: temp1_input: 42.000 temp1_crit: 110.000 coretemp-isa-0000 Adapter: ISA adapter Core 0: temp2_input: 43.000 temp2_crit: 100.000 temp2_crit_alarm: 0.000 Core 1: temp3_input: 43.000 temp3_crit: 100.000 temp3_crit_alarm: 0.000 Can anybody please tell me how to add the above sensors to thermal-conf.xml, and maybe also how to locate and add other cooling devices?

I would like to change the fan speeds on my PC. In the Asus BIOS settings, this is possible with PWM and DC (three of them are connected with 4 pins), but the running operating system seems to have problems doing the same. The two I want to change manually have the names CHA_1FAN and CHA_2FAN on the motherboard. > cat /etc/sensors3.conf | grep -i fan # Fans label fan1 "PSU Fan" label fan2 "CPU Fan" label fan3 "System FAN2" label fan4 "System FAN3" label fan5 "System FAN4" # Fans label fan1 "CPU Fan" label fan2 "System FAN2" label fan3 "System FAN3" label fan4 "System FAN4" label fan7 "PSU Fan" > hwinfo | grep -i fan acpi-fan: /devices/platform/PNP0C0B:03 acpi-fan: /devices/platform/PNP0C0B:01 acpi-fan: /devices/platform/PNP0C0B:04 acpi-fan: /devices/platform/PNP0C0B:02 acpi-fan: /devices/platform/PNP0C0B:00 acpi-fan: module = fan type = "", modalias = "acpi:PNP0C0B:", driver = "acpi-fan" type = "", modalias = "acpi:PNP0C0B:", driver = "acpi-fan" type = "", modalias = "acpi:PNP0C0B:", driver = "acpi-fan" type = "", modalias = "acpi:PNP0C0B:", driver = "acpi-fan" type = "", modalias = "acpi:PNP0C0B:", driver = "acpi-fan" E: DRIVER=acpi-fan E: DRIVER=acpi-fan E: DRIVER=acpi-fan E: DRIVER=acpi-fan E: DRIVER=acpi-fan [ 0.062442] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 fan 20480 0 - Live 0x0000000000000000 Driver Status: thermal,fan are active Driver Activation Cmd: "modprobe thermal; modprobe fan" > sudo pwmconfig [sudo] password for root: # pwmconfig revision $Revision$ ($Date$) [...] /usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed heimchen@DESKTOP-G0NG8DL / > The system is OpenSuse Leap 15.5 and lm-sensor does not seem to be installed. I tried downloading it from source and compile it, which worked but there is still nothing with this name on my disk.

What is the best way to get the CPU temperature on Linux from the command line? On one small portable system, I was able to get the CPU temperature from here:

/sys/class/thermal/thermal_zone0/temp

or here:

/sys/class/thermal/thermal_zone1/temp

However some people say to look for the "coretemp" value, which doesn't seem to exist on my system. Is there an official best practice for getting CPU temperature?

What are the commands to find out fan speed and cpu temp in linux (I know lm-sensor can do the task). Is there any alternative for that?

I have a Gigabyte X570 GAMING X motherboard and want to control the fans from my XUbuntu 24.04, but it has issues detecting the fans. There is [a suggested solution](https://github.com/lm-sensors/lm-sensors/issues/154) , but modprobe it87 force_id=0x8628 only works on the console (I don't want to use dkms). Now I want this to work directly after a reboot. So I now have: root@runlikehell:~# cat /etc/modprobe.d/fans.conf options it87 force_id=0x8628 root@runlikehell:~# and added these to the "[Unit]"-section in /usr/lib/systemd/system/lm-sensors.service: Requires=systemd-modules-load.service After=systemd-modules-load.service Note that I asked AI and it halucinates as it suggests this: After=modprobe@*.service Wants=modprobe@*.service but [systemd doesn't allow wildcards there](https://github.com/systemd/systemd/issues/5388) . After a reboot I see this, so the conf-file was loaded: root@runlikehell:~# modprobe -c | grep it87 blacklist it8712f_wdt blacklist it87_wdt blacklist it8712f_wdt blacklist it87_wdt blacklist it8712f_wdt blacklist it87_wdt blacklist it8712f_wdt blacklist it87_wdt blacklist it8712f_wdt blacklist it87_wdt blacklist it8712f_wdt blacklist it87_wdt blacklist it8712f_wdt blacklist it87_wdt blacklist it8712f_wdt blacklist it87_wdt options it87 force_id=0x8628 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*AB350*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*AX370*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*B550AORUSPROAC*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*TRX40AORUSXTREME*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570AORUSMASTER*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570AORUSPRO*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570AORUSPROWIFI*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*X570SAEROG*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z390AORUSULTRA_CF*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z690AORUSPRO*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z690AORUSPRODDR4*: it87 alias dmi*:rvn*GigabyteTechnologyCo.,Ltd.*:rn*Z97X_GamingG1*: it87 alias dmi*:rvn*nVIDIA*:rn*FN68PT*: it87 root@runlikehell:~# The lm-sensors.service is running, but it didn't find the it87-related stuff: root@runlikehell:~# journalctl -b 0 -u lm-sensors.service ... systemd: Starting lm-sensors.service - Initialize hardware monitoring sensors... ... sensors: k10temp-pci-00c3 ... sensors: Adapter: PCI adapter ... sensors: Tctl: +48.4°C ... sensors: Tccd1: +56.5°C ... sensors: acpitz-acpi-0 ... sensors: Adapter: ACPI interface ... sensors: temp1: +16.8°C ... sensors: temp2: +16.8°C ... sensors: temp3: +16.8°C ... sensors: gigabyte_wmi-virtual-0 ... sensors: Adapter: Virtual device ... sensors: temp1: +25.0°C ... sensors: temp2: +26.0°C ... sensors: temp3: +48.0°C ... sensors: temp4: +26.0°C ... sensors: temp5: +28.0°C ... sensors: temp6: +39.0°C ... sensors: nvme-pci-0300 ... sensors: Adapter: PCI adapter ... sensors: Composite: +40.9°C (low = -0.1°C, high = +74.8°C) ... sensors: (crit = +79.8°C) ... systemd: Finished lm-sensors.service - Initialize hardware monitoring sensors. root@runlikehell:~# So to me it means that the configuration of modprobe hasn't been read or applied when lm-sensors.service starts. journalctl -b 0 doesn't contain "it87" at all (I don't know if it should). How do I run the lm-sensors.service after the modprobe-stuff properly?

As my CPU cooler fan broke on a setup with older hardware, I had to replace it with a similar fan, which unfortunately is pretty noisy. I am using the following system: - Mainboard Gigabyte F2A88X-Up4 - CPU AMD A10-7850k radeon r7 - Debian GNU/Linux 9 (stretch) 64-bit The fan is permanently running at 3770 RPM and I am looking for a way to manually reduce the speed. There is an option in the BIOS to set the fan to a "silent" mode, but it does not have any effect. I then installed

-sensors

and

. Running the sensors I get the following output:

-pci-00c4
Adapter: PCI adapter
power1:           N/A  (crit =  95.09 W)

it8620-isa-0228
Adapter: ISA adapter
in0:          +0.70 V  (min =  +0.00 V, max =  +3.06 V)
in1:          +1.50 V  (min =  +0.00 V, max =  +3.06 V)
in2:          +2.03 V  (min =  +0.00 V, max =  +3.06 V)
in3:          +2.05 V  (min =  +0.00 V, max =  +3.06 V)
in4:          +2.05 V  (min =  +0.00 V, max =  +3.06 V)
in5:          +2.23 V  (min =  +0.00 V, max =  +3.06 V)
in6:          +2.23 V  (min =  +0.00 V, max =  +3.06 V)
3VSB:         +3.29 V  (min =  +0.00 V, max =  +6.12 V)
Vbat:         +2.69 V  
fan1:        3770 RPM  (min =    0 RPM)
fan2:           0 RPM  (min =    0 RPM)
fan3:           0 RPM  (min =    0 RPM)
fan4:           0 RPM  (min =    0 RPM)
fan5:           0 RPM  (min =    0 RPM)
temp1:        +22.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp2:         -8.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = thermistor
temp3:        +13.0°C  (low  = +127.0°C, high = +127.0°C)  sensor = Intel PECI
temp4:        +45.0°C  
temp5:        +45.0°C  
temp6:        +45.0°C  
intrusion0:  ALARM

radeon-pci-0008
Adapter: PCI adapter
temp1:        -11.0°C  (crit = +120.0°C, hyst = +90.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
temp1:         +0.0°C  (high = +70.0°C)
                       (crit = +80.0°C, hyst = +79.0°C)

I then ran the fancontrol configuration script with

:

the following devices:
   hwmon0 is it8620
   hwmon1 is k10temp
   hwmon2 is fam15h_power
   hwmon3 is radeon

Found the following PWM controls:
   hwmon0/pwm1           current value: 0
   hwmon0/pwm2           current value: 0
   hwmon0/pwm3           current value: 0
   hwmon0/pwm4           current value: 255
   hwmon0/pwm5           current value: 255

Giving the fans some time to reach full speed...
Found the following fan sensors:
   hwmon0/fan1_input     current speed: 3792 RPM
   hwmon0/fan2_input     current speed: 0 ... skipping!
   hwmon0/fan3_input     current speed: 0 ... skipping!
   hwmon0/fan4_input     current speed: 0 ... skipping!
   hwmon0/fan5_input     current speed: 0 ... skipping!

So I am trying to reduce the speed of

/fan1_input

. Running the test, which did not stop my CPU fan, I got the following result:

pwm control hwmon0/pwm1 ...
  hwmon0/fan1_input ... speed was 3792 now 3750
    no correlation

No correlations were detected.
There is either no fan connected to the output of hwmon0/pwm1,
or the connected fan has no rpm-signal connected to one of
the tested fan sensors. (Note: not all motherboards have
the pwm outputs connected to the fan connectors,
check out the hardware database on http://www.almico.com/forumindex.php) 

Did you see/hear a fan stopping during the above test (n)?

Based on this result I assume that I cannot control my CPU fan with

? Or is it possible to write a manual configuration for the fan in

/etc/fancontrol

despite the previous output? I would appreciate your feedback.

**Edit:** The original question of this post was regarding the "average" cpu MHz as obtained via conky builtins and the command line. A further question was regarding temperatures as reported by conky vs temperatures obtained via the command line. A tertiary question was regarding per core MHz as reported by both methods. 1. The "average" MHz question has been rendered superfluous by my discovery that I'd messed up my conkey.conf file a very long time ago. There is no average cpu MHz variable in the current version of conky, and there might not have ever been. In addition. it's such a transitory measurement, I'm not sure it's actually useful at all - at least for me. 2. @terdon requested a minimal conkyrc file so other people could try to reproduce what I said I was experiencing. So I created one. I'll include it below. But creating it allowed me to see I was seeing what I expected to see - not what was actually there. It turns out that the command I had been using to get the cpu temp - ${hwmon 1 temp 3}, actually is the cpu die teperature plus the Tctl offset for fan control. The actual cpu temp can be obtained with this command: ${exec sensors -f k10temp-pci-00c3 | grep Tccd1 | cut -b 15-21}F. I don't see a way to get the actual cpu temp through conky's builtins. 3. The per core MHz question as reported by conky's builtins, and the command line. This question is still out there, but I think I know whats going, I just haven't proved it yet. At least to myself. I created the requested conky.conf - I don't use a conkyrc file. And running it next to my actual conky was giving me really interesting results. So I created another version, identical to the other, but one being aligned to the middle_left, and the other being aligned to the middle_middle. In these conky.conf files, I'm using both the builtins, and getting the stats from an exec command. Interestingly, all 4 sets of data from these two conky instances will often align very well. Sometimes almost perfectly! That was actually surprising. And the data being reported from my actual conky was almost always in the 3-4 GHz range, while the two test conky's was almost always in the 2 GHz range... So, what I think is going on is my 'production' conky.conf is rather large - with lots and lots going on. and it kicks up the cpu frequency while it's running. And then when the test conky.confs are running, they show lower GHz because they're actually being less demanding. Does this sound reasonable? Here's the test conky.conf: conky.config = { alignment = 'middle_left', background = false, update_interval = 1.5, cpu_avg_samples = 2, out_to_console = false, override_utf8_locale = true, double_buffer = true, text_buffer_size = 8192, own_window = true, own_window_transparent = true, own_window_argb_visual = true, own_window_type = 'normal', own_window_argb_value = 0, own_window_hints = 'undecorated,below,sticky,skip_taskbar,skip_pager', border_inner_margin = 20, border_outer_margin = 0, font = 'monospace:size=10', gap_x = 350, gap_y = 0, minimum_width = 450, minimum_height = 450, draw_borders = false, use_xft = true, xftalpha = 0.8, uppercase = false, maximum_width = 1024, temperature_unit = "fahrenheit", } conky.text = [[ CPU Temp: Conky Builtin 1 3: ${hwmon 1 temp 3}°F Using hwmon: ${exec awk '{print ((($0 / 1000)*1.8)+32) }' < /sys/class/hwmon/hwmon1/temp3_input }°F # Temp of the die plus the Tctl offset for fan control Using sensors Tctl : ${exec sensors -f k10temp-pci-00c3 | grep Tctl | cut -b 15-21}F # Temp of the die itself Using sensors Tccd1: ${exec sensors -f k10temp-pci-00c3 | grep Tccd1 | cut -b 15-21}F Average CPU Frequency: ${exec cat /proc/cpuinfo |grep "cpu MHz"| awk '{sum+=$4;} END{printf "%2.2f", (sum/12)/1000;}'} GHz CPU1: ${freq_g 1} GHz ${goto 170}CPU1: ${exec awk '{printf "%2.2f", ($0)/1000000;}' conky to gather, and display my Linux system stats for a long time. I noticed over a decade ago that the 'average' cpu MHz just copies the first core, it isn't an average of all cores. The command to get the average cpu frequency in conky is: ${freq_g 0}. To get the cores individually, you just use ${freq_g 1} - ${freq_g 12}. In other words, 0 is supposed to be the average, not the first core, and individually, you start counting at 1, through how many cores you have. But 0 and 1 both always display the exact same thing. Checking in bash, I run this command: grep "cpu MHz" corectrl to control the cpu governor, and control the gpu. When I set the cpu to 'performance mode', the frequency of the cpu jumps up accordingly - from the low 2 GHz range, to the low 4 GHz range, as reported by conky. But when I check the output with the above grep command, all the cores are showing that they're running in the low to mid 3 GHz range. I'm not really expecting precision numbers here, just pretty close ballpark numbers. Or, in other words, I expect precision numbers, but they're going to change so many time per second that I expect them to be reported differently. The biggest problem I'm having is that my grep command rarely shows the cpu frequency going above 4 GHz, while conky rarely shows it below 4 GHz - in performance mode. Should I just display the outputs from my grep command in conky, and just accept the two outputs aren't going to jive? ---- I'm having a very similar issue with conky's built in cpu temperature detection. I can display what conky's builtin is reporting, and the results using sensors, and hwmon. The conky builtin is almost always showing the lowest temperature. The other two methods bounce around a lot more, and usually show higher temperatures then conky's builtin. And I mean they might show a ten degree difference, or more, for a long time.

I have a temp/humidity sensor connected to the i2c-0 interface on a Raspberry Pi: Rpi OS ver 'bookworm'. It works fine, and I can read sensor values from the files in /sys/class/hwmon/hwmon2 (or equivalently in /sys/bus/i2c/devices/0-0044/hwmon/hwmon2 or /sys/devices/platform/soc/3f205000.i2c/i2c-0/0-0044/hwmon/hwmon2) using a bash script:

#!/usr/bin/bash
dev_folder='/sys/class/hwmon/hwmon2'
humid_r=$(To minimize the risk of breaking users of sysfs, which are in most cases low-level userspace applications, with a new kernel release, the users of sysfs must follow some rules to use an as-abstract-as-possible way to access this filesystem. The current udev and HAL programs already implement this and users are encouraged to plug, if possible, into the abstractions these programs provide instead of accessing sysfs directly.

I take this to mean that instead of accessing the sensor data directly from sysfs - as I'm currently doing in my bash script - I should be using udev.  

I've also read a bit on udev. *My current understanding of udev* is that **one way** udev might help me is to *"translate"* the **variable** sysfs folder name into a **fixed** one (or at least a fixed symlink). This is apparently done on the basis of .rule files that contain a series of *device attributes* used as *filters* (aka **match keys**), followed by a *command* (aka **assignment key**). The *device attributes* I used were selected from the [output of this command](https://pastebin.com/VGLxA5vp) :

bash udevadm info --attribute-walk --path=/sys/bus/i2c/devices/0-0044/hwmon/hwmon2

I created the following udev *rule file*:

# filename: /etc/udev/rules.d/80-local.rules ACTION=="add", SUBSYSTEM=="hwmon", ATTR{name}=="sht3x", KERNELS=="0-0044", SUBSYSTEMS=="i2c", NAME="sht30", SYMLINK+="i2c_sht3x"

This rule was derived from a variety of sources, and guesswork using a *trial-and-error* approach. The *filtering* part of the rule seems to work: I've tested the rule using a script to create a /tmp file. However, the NAME="sht30" and SYMLINK+="i2c_sht3x" fails to create a corresponding entry in my /dev folder as I expected (hoped) it would. 

I've also tried *variants* of this rule that attempted to create a symlink in sysfs; i.e. /sys/class/hwmon/hwmon_sht3x. But this didn't work either - it seems the symlinks are restricted to the /dev folder?? And I've looked at man udevadm for something I overlooked, but found nothing that helped me. 

Persistence often pays, and so I modified the above rule as follows:

# filename: /etc/udev/rules.d/80-local.rules ACTION=="add", SUBSYSTEM=="hwmon", ATTR{name}=="sht3x", KERNELS=="0-0044", SUBSYSTEMS=="i2c", RUN+="/bin/sh -c 'ln -s /sys$devpath /dev/hwmon_sht3x'" ``` And this rule actually works! (so far at least): It creates the symlink /dev/hwmon_sht3x to /sys/devices/platform/soc/3f205000.i2c/i2c-0/0-0044/hwmon/hwmon2 - **OR** to the folder currently assigned by the kernel. I've tested it several times by forcing a change to hwmonX, and it (so far) hasn't failed. So, the question is: #### Why will the matching rule not create the SYMLINK+="i2c_sht3x"?

I have ran sensors-detect and lm_sensors still returns the following. radeon-pci-0100 Adapter: PCI adapter temp1: +511.0°C (crit = +120.0°C, hyst = +90.0°C) coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +47.0°C (high = +87.0°C, crit = +105.0°C) Core 0: +46.0°C (high = +87.0°C, crit = +105.0°C) Core 1: +47.0°C (high = +87.0°C, crit = +105.0°C)

I have recently bought a motherboard of the PowerX model having an Intel H61 chipset -- [this one](https://www.power-x.in/products/power-x-motherboard-pmb-h61-ddr3) . I ran the sensors command and it shows only the CPU temperatures. Fan speed is not available. Running sensors-detect did not help. By looking at the hardware, I can see there are 4 pins for the CPU fan, so reading fan speed & PWM control should work. On another motherboard, I got the CPU fan speed and could also control the fan speed. Looks like Linux has less support for the PowerX motherboard or the appropriate drivers are not loaded. How can I manually probe the motherboard for sensors and PWM controls? Is there any online documentation available for this motherboard?

I tried

'sensors | sudo docker stats'

'docker stats | watch sensors'

docker stats | sudo watch sensors

So I assume its not possible to display both outputs in one window? Other than installing something like glances? Any advice would be appreciated.

Since the motherboard's IT8688E chip is not supported I forced the 8628 one as in this Github lm-sensors issue and it detected all sensors correctly. This is what I did to make it work: - Added acpi_enforce_resources=lax to GRUB_CMDLINE_LINUX in /etc/default/grub. - Created the /etc/modules-load.d/it87.conf file with a it87 line - Created the /etc/modprobe.d/it87.conf file with a options it87 force_id=0x8628 line - # grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg But then plasma was freezing when logging out and I undid everything. Now I get this at boot:

out 07 07:09:44 d3.localdomain kernel: it87: Found IT8628E chip at 0xa40, revision 1
out 07 07:09:44 d3.localdomain kernel: it87: Beeping is supported
out 07 07:09:44 d3.localdomain kernel: ACPI Warning: SystemIO range 0x0000000000000A45-0x0000000000000A46 conflicts with OpRegion 0x0000000000000A45-0x0000000000000A46 (\GSA1.SIO1) (20200528/utaddress-204)
out 07 07:09:44 d3.localdomain kernel: ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
out 07 07:09:44 d3.localdomain kernel: fuse: init (API version 7.31)
out 07 07:09:44 d3.localdomain systemd: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
out 07 07:09:44 d3.localdomain systemd: systemd-modules-load.service: Failed with result 'exit-code'.
out 07 07:09:44 d3.localdomain systemd: Failed to start Load Kernel Modules.
out 07 07:09:44 d3.localdomain kernel: audit: type=1130 audit(1602065384.576:2): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-modules-load comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

How to get rid off it?

$ uname -a
Linux d3.localdomain 5.8.13-200.fc32.x86_64 #1 SMP Thu Oct 1 21:49:42 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I have a Ryzen 3950X cpu. In the Asus Bios, I sent the fans to spin at 100% RPM at a temperature of 70C. However, they definitely don't spin at 100% RPM at 70C. The temperature needs to reach 75C-80C before they reach 100% From looking at Google, this might be because running sensors on Linux is not as accurate as using "Ryzen Master" on Windows. Are they any good Linux substitutes?

The core number is 0,4,8,.....39 in the sensors command. Why not 0,1,2,3,4.....?

foo@foo-linux:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +73.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +46.0°C  (high = +80.0°C, crit = +100.0°C)
Core 4:        +50.0°C  (high = +80.0°C, crit = +100.0°C)
Core 8:        +52.0°C  (high = +80.0°C, crit = +100.0°C)
Core 12:       +47.0°C  (high = +80.0°C, crit = +100.0°C)
Core 16:       +73.0°C  (high = +80.0°C, crit = +100.0°C)
Core 20:       +50.0°C  (high = +80.0°C, crit = +100.0°C)
Core 24:       +58.0°C  (high = +80.0°C, crit = +100.0°C)
Core 28:       +52.0°C  (high = +80.0°C, crit = +100.0°C)
Core 36:       +48.0°C  (high = +80.0°C, crit = +100.0°C)
Core 37:       +48.0°C  (high = +80.0°C, crit = +100.0°C)
Core 38:       +48.0°C  (high = +80.0°C, crit = +100.0°C)
Core 39:       +48.0°C  (high = +80.0°C, crit = +100.0°C)

**update again** This is a 12th Gen Intel(R) Core(TM) i7-12700 This is a PC, not a server, with only 1 CPU socket. **update**

foo@foo-linux:~$ cat /proc/cpuinfo | grep -i apicid
apicid		: 0
initial apicid	: 0
apicid		: 1
initial apicid	: 1
apicid		: 8
initial apicid	: 8
apicid		: 9
initial apicid	: 9
apicid		: 16
initial apicid	: 16
apicid		: 17
initial apicid	: 17
apicid		: 24
initial apicid	: 24
apicid		: 25
initial apicid	: 25
apicid		: 32
initial apicid	: 32
apicid		: 33
initial apicid	: 33
apicid		: 40
initial apicid	: 40
apicid		: 41
initial apicid	: 41
apicid		: 48
initial apicid	: 48
apicid		: 49
initial apicid	: 49
apicid		: 56
initial apicid	: 56
apicid		: 57
initial apicid	: 57
apicid		: 72
initial apicid	: 72
apicid		: 74
initial apicid	: 74
apicid		: 76
initial apicid	: 76
apicid		: 78
initial apicid	: 78

I use Debian linux squeeze x64 now on gigabyte 970a-DS3. I installed this OS on motherboard which burned (from asus). And I've changed my motherboard to that gigabyte. After running back into linux, it shows I have only 13,9 °C temperatures and is it only 1 sensor (instead of about 3 or 4 sensors), which it has detected. it shows just: Debx64>sensors k10temp-pci-00c3 Adapter: PCI adapter temp1: +13.9°C (high = +70.0°C, crit = +86.0°C) I searched on google, but nothing there helping me. I was trying to reinstall lm_sensors, trying again sensors-detect |y and nothing was working. Why it doesn't show all of my sensors and why it shows only 1 sensors with totaly low temperature (13.9°C is epic fail...) What to do, to fix this problem? Is there anything how to tell linux "I want to search again all devices, which has any sensors"? I know this is unique problem, but I would like to know, how to solve this problem. Thank you, all for helping me

I have a new desktop computer with Intel i7-12700 32GB RAM. I am doing build code stuff, I use the sensors command to check CPU temperature, and I found most of the cores are @ 100C. Is that normal? Will CPU hardware itself control the frequency to fit the temperature? **update** I checked dmesg and found many logs as below:

mce: CPUxx: Package temperature above threshold, cpu clock throttled

It looks like the CPU control itself not higher than 100C.

I have a tablet with builtin sensors which allow me automatic screen rotation, based on iio-sensors-proxy. However, the screen orientation is off, and I need to fix it. On it's GitHub page (https://github.com/systemd/systemd/blob/master/hwdb/60-sensor.hwdb) is explained how to change this behavior: Create a file /etc/udev/hwdb.d/61-sensor-local.hwdb and write to it sensor:modalias::dmi: and ACCEL_MOUNT_MATRIX=1, 0, 0; 0, 1, 0; 0, 0, 1 (this matrix has to be changed ofc). # Problem : I have no idea how to get the neccessary information for the first line, the sensor-prefix. # Solution : Final file contains: sensor:modalias:acpi:KIOX000A*:dmi:*:svnEVE*:pnEveV:* ACCEL_MOUNT_MATRIX=0, 1, 0; -1, 0, 0; 0, 0, 1 What I've found so far: This gives me device name: udevadm info --export-db | grep iio P: /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-KIOX000A:00/iio:device0 N: iio:device0 E: DEVNAME=/dev/iio:device0 E: DEVPATH=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-KIOX000A:00/iio:device0 E: DEVTYPE=iio_device E: IIO_SENSOR_PROXY_TYPE=iio-buffer-accel E: SUBSYSTEM=iio E: SYSTEMD_WANTS=iio-sensor-proxy.service This gives me more info about the device: udevadm info -n "/dev/iio:device0" P: /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-KIOX000A:00/iio:device0 N: iio:device0 E: DEVNAME=/dev/iio:device0 E: DEVPATH=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-KIOX000A:00/iio:device0 E: DEVTYPE=iio_device E: IIO_SENSOR_PROXY_TYPE=iio-buffer-accel E: MAJOR=245 E: MINOR=0 E: SUBSYSTEM=iio E: SYSTEMD_WANTS=iio-sensor-proxy.service E: TAGS=:systemd: E: USEC_INITIALIZED=1959744 And via pci I find the so-called modalias: cat /sys/devices/pci0000:00/0000:00:15.0/modalias pci:v00008086d00009D60sv00008086sd00007270bc11sc80i00 Would really appreciate help from here on! --- My system: Linux jva 4.14.5-1-ARCH #1 SMP PREEMPT Sun Dec 10 14:50:30 UTC 2017 x86_64 GNU/Linux running under GNOME 3.26.2 (Wayland-seesion) Tablet: Eve V i7Y

I am trying to read one sample from a sensor using libiio, but for some reason I always get the same sample unless I restart the application. Here is a minimal example

#include 
#include 
#include 
#include 
#include 


/* Global objects */
static struct iio_buffer *device_buffer = NULL;
static struct iio_channel *channel = NULL;
static struct iio_context *local_ctx = NULL;
static struct iio_device *dev = NULL;
static const char *dev_name = NULL;
static const char *channel_id = NULL;
static uint8_t *in_buf;


int main()
{

        /* Getting local iio device context */
        local_ctx = iio_create_local_context();
        dev = iio_context_get_device(local_ctx, 0);
        dev_name = iio_device_get_name(dev);
        channel = iio_device_get_channel(dev, 0);

        iio_channel_enable(channel);
        if (iio_channel_is_enabled(channel))
                return -1;

        uint32_t sample_size = 3;
        uint32_t buffer_length = 1;

        struct iio_buffer *device_buffer =
                iio_device_create_buffer(dev, buffer_length, false);

        if (!device_buffer)
                return -1;

        while (true) {
                ssize_t nbytes_rx = iio_buffer_refill(device_buffer);

                if (nbytes_rx <= 0) {
                        printf("Error refilling buf %d\n", (int) nbytes_rx);
                        return -1;
                }

                in_buf = (uint8_t*)malloc(sample_size * buffer_length);
                iio_channel_read(channel, device_buffer, in_buf, sample_size * buffer_length);
                printf("%" PRIi32 "\n", ((int32_t *)in_buf));
                free(in_buf);

        }
}

In the actual code I am properly error checking, handling SIGINT and destroying all the buffers. Everything works. The only issue is that the same sample is printed over and over, whereas I would assume the buffer to get refilled and a new sample to get printed.

I am trying to boot AntiX LiveCD on my old Toshiba A200 laptop with 2 GB of RAM. But when I accidentally launched the "sensors" in the terminal, I saw that the CPU temperature was 70°C! I turned off the laptop and turned it on again, and the fan revved up to the maximum. It turns out that antiX stops the fan? What should I do in this case?

I am using lm sensor in my embedded linux. It is working fine. When I am executing the sensors command I am getting following data. lm75-i2c-0-48 Adapter: 21a0000.i2c temp1: +28.5 C (high = +80.0 C, hyst = +75.0 C) lm75-i2c-0-49 Adapter: 21a0000.i2c temp1: +26.5 C (high = +80.0 C, hyst = +75.0 C) eth0_dsa0-virtual-0 Adapter: Virtual device temp1: +35.0 C (high = +100.0 C) mx_thermal_zone-virtual-0 Adapter: Virtual device temp1: +10.5 C (crit = +85.0 C) I want to know which temperature belongs to which sensor. Like what is the cpu temperature and what is environment temperature. Thank You.