Sensors not available? [Solved]

[debianix]

Hello!
I have just noticed that when I post the QSI here in the forum:

Code: Select all

Snapshot created on: 20240625_0332
System:
  Kernel: 6.1.0-21-amd64 [6.1.90-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/vmlinuz-6.1.0-21-amd64 root=UUID=<filter> ro quiet splash
    resume=UUID=<filter> resume_offset=626688
  Desktop: KDE Plasma v: 5.27.5 wm: kwin_x11 vt: 7 dm: SDDM Distro: MX-23.3_KDE_x64 Libretto May
    19 2024 base: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Desktop Mobo: Gigabyte model: B560M DS3H V2 serial: <superuser required> UEFI: American
    Megatrends LLC. v: F9 date: 06/07/2023
CPU:
  Info: model: 11th Gen Intel Core i7-11700 bits: 64 type: MT MCP arch: Rocket Lake gen: core 11
    level: v4 note: check built: 2021+ process: Intel 14nm family: 6 model-id: 0xA7 (167) stepping: 1
    microcode: 0x5D
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache: L1: 640 KiB
    desc: d-8x48 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB L3: 16 MiB desc: 1x16 MiB
  Speed (MHz): avg: 800 high: 801 min/max: 800/4800:4900 scaling: driver: intel_pstate
    governor: powersave cores: 1: 801 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800 9: 800 10: 800
    11: 800 12: 800 13: 801 14: 800 15: 800 16: 800 bogomips: 79872
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling mitigation: Microcode
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed mitigation: Enhanced IBRS
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Enhanced / Automatic IBRS; IBPB: conditional; RSB filling;
    PBRSB-eIBRS: SW sequence; BHI: SW loop, KVM: SW loop
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel RocketLake-S GT1 [UHD Graphics 750] vendor: Gigabyte driver: i915 v: kernel
    arch: Gen-12.1 process: Intel 10nm built: 2020-21 ports: active: DP-1,HDMI-A-3
    empty: HDMI-A-1,HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:4c8a class-ID: 0300
  Device-2: AIRHUG 02 type: USB driver: uvcvideo bus-ID: 3-2:2 chip-ID: 2f9d:1101 class-ID: 0e02
    serial: <filter>
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: i915 display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3840x1080 s-dpi: 96 s-size: 1016x285mm (40.00x11.22")
    s-diag: 1055mm (41.54")
  Monitor-1: DP-1 pos: primary,left model: BenQ BL2410 serial: <filter> built: 2015
    res: 1920x1080 hz: 60 dpi: 102 gamma: 1.2 size: 477x268mm (18.78x10.55") diag: 609mm (24")
    ratio: 16:9 modes: max: 1920x1080 min: 720x400
  Monitor-2: HDMI-A-3 mapped: HDMI-3 pos: right model: BenQ BL2410 serial: <filter> built: 2015
    res: 1920x1080 hz: 60 dpi: 102 gamma: 1.2 size: 477x268mm (18.78x10.55") diag: 609mm (24")
    ratio: 16:9, 15:9 modes: max: 1920x1080 min: 720x400
  API: OpenGL v: 4.6 Mesa 23.1.2-1~mx23ahs renderer: Mesa Intel Graphics (RKL GT1)
    direct-render: Yes
Audio:
  Device-1: Intel Tiger Lake-H HD Audio vendor: Gigabyte driver: snd_hda_intel v: kernel
    bus-ID: 1-3:2 alternate: snd_sof_pci_intel_tgl chip-ID: 08bb:2902 bus-ID: 00:1f.3 class-ID: 0300
    chip-ID: 8086:43c8 class-ID: 0403
  Device-2: Texas Instruments PCM2902 Audio Codec type: USB
    driver: hid-generic,snd-usb-audio,usbhid
  Device-3: C-Media Audio Adapter (Unitek Y-247A) type: USB
    driver: cmedia_hs100b,snd-usb-audio,usbhid bus-ID: 3-4:3 chip-ID: 0d8c:0014 class-ID: 0300
  API: ALSA v: k6.1.0-21-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Gigabyte driver: r8169
    v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 03:00.0 chip-ID: 10ec:8168
    class-ID: 0200
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
  Local Storage: total: 3.17 TiB used: 1.13 TiB (35.8%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: SSD 970 EVO Plus 1TB size: 931.51 GiB
    block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 2B2QEXM7 temp: 43.9 C scheme: GPT
  ID-2: /dev/nvme1n1 maj-min: 259:1 vendor: Samsung model: SSD 970 EVO Plus 2TB size: 1.82 TiB
    block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
    rev: 2B2QEXM7 temp: 42.9 C scheme: GPT
  ID-3: /dev/sda maj-min: 8:0 vendor: Kingston model: SA400S37480G size: 447.13 GiB block-size:
    physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 60.1 scheme: GPT
Partition:
  ID-1: / raw-size: 68.34 GiB size: 66.72 GiB (97.62%) used: 56.83 GiB (85.2%) fs: ext4
    dev: /dev/dm-0 maj-min: 253:0 mapped: luks-<filter>
  ID-2: /boot raw-size: 1024 MiB size: 973.4 MiB (95.06%) used: 106.3 MiB (10.9%) fs: ext4
    dev: /dev/nvme0n1p2 maj-min: 259:3
  ID-3: /boot/efi raw-size: 1024 MiB size: 1022 MiB (99.80%) used: 288 KiB (0.0%) fs: vfat
    dev: /dev/nvme0n1p1 maj-min: 259:2
  ID-4: /home raw-size: 861.14 GiB size: 846.54 GiB (98.31%) used: 4.22 GiB (0.5%) fs: ext4
    dev: /dev/dm-2 maj-min: 253:2 mapped: luks-<filter>
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 37.14 GiB used: 0 KiB (0.0%) priority: -2 file: /swap/swap
Sensors:
  System Temperatures: cpu: 33.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Repos:
  Packages: 2990 pm: dpkg pkgs: 2979 libs: 1547 tools: apt,apt-get,aptitude,nala,synaptic pm: rpm
    pkgs: 0 pm: flatpak pkgs: 11
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/repo/ bookworm main non-free
    2: deb http://ftp.halifax.rwth-aachen.de/mxlinux/packages/mx/repo/ bookworm ahs
Info:
  Processes: 332 Uptime: 36m wakeups: 1 Memory: 31.14 GiB used: 4.34 GiB (13.9%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI

"fan speeds" and "mobo" are both displayed as "N/A".
However, I have several fans installed in my computer and they all work.
I've never had any major problems with temperatures inside the PC case because the case is relatively large and not crowded, and there are several fans.

Now I'm wondering on the one hand:
Is there something wrong with the sensors and how can I get to the bottom of it?

and on the other hand :
assuming the sensors are working (again): if I add a tool like "plasma system monitor" in the system tray bar, with which I can clearly see the temperatures and fan speeds, can I then also configure this tool so that I am warned if there is too much temperature in one place, and/or perhaps it is even possible for the fans to automatically turn more so that the temperature is equalized? So I would prefer an "all-in-one solution" to ensure that everything is always right with the temperatures etc., that I am warned in good time if this is not the case, and where I can also intervene if necessary if I notice that a certain area is always getting too hot, for example?
Is this even possible without having extreme hardware knowledge?


I look forward to your tips on this

[siamhie]

Not all motherboards are capable of reporting that type of information to the OS. My motherboard (MSI B550-A Pro) shows this in QSI.

Code: Select all

Sensors:
  System Temperatures: cpu: 42.1 C mobo: N/A gpu: amdgpu temp: 46.0 C mem: 48.0 C
  Fan Speeds (RPM): N/A gpu: amdgpu fan: 757

If I go into the BIOS I can see the speed of the CPU and case fans in there.

[Stevo]

What do you get when you run "sensors" in the terminal?

You could also try adding and running a newer kernel, since your hardware is fairly recent, to see if the acpi module in the newer kernel supports more of your hardware. But it's your choice...

"If it aint broke, don't fix it."

versus

"Set it to 11!"
"Test to destruction!"

(Adding a recent kernel looks 110% safe with your hardware and drivers in use)

[debianix]

Code: Select all

$ sensors
nvme-pci-0600
Adapter: PCI adapter
Composite:    +55.9°C  (low  = -273.1°C, high = +84.8°C)
                       (crit = +84.8°C)
Sensor 1:     +55.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +77.8°C  (low  = -273.1°C, high = +65261.8°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +16.8°C  (crit = +20.8°C)
temp2:        +27.8°C  (crit = +105.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +34.0°C  (high = +80.0°C, crit = +100.0°C)
Core 0:        +30.0°C  (high = +80.0°C, crit = +100.0°C)
Core 1:        +32.0°C  (high = +80.0°C, crit = +100.0°C)
Core 2:        +30.0°C  (high = +80.0°C, crit = +100.0°C)
Core 3:        +31.0°C  (high = +80.0°C, crit = +100.0°C)
Core 4:        +34.0°C  (high = +80.0°C, crit = +100.0°C)
Core 5:        +31.0°C  (high = +80.0°C, crit = +100.0°C)
Core 6:        +33.0°C  (high = +80.0°C, crit = +100.0°C)
Core 7:        +32.0°C  (high = +80.0°C, crit = +100.0°C)

nvme-pci-0100
Adapter: PCI adapter
Composite:    +46.9°C  (low  = -273.1°C, high = +84.8°C)
                       (crit = +84.8°C)
Sensor 1:     +46.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +48.9°C  (low  = -273.1°C, high = +65261.8°C)

Well I absolutely see ur point with newer kernels. I'm more of the "set and forget" type, which works great with the Debian kernel that gets updates automatically.
The Liquorix kernel is certainly also great, I would use it straight away, but I would then check manually relatively often to see what the availability is like and whether security patches are still coming for the installed version, etc.

If I install Liquorix 6.8.12-1 from MXPI, for example, and everything works great and snappy, how do I know when it's time to choose the next higher version? And above all, my hardware, which is relatively up-to-date now, might not be in a few years' time. As soon as this scenario would occur again, I would probably switch back to the Debian stable kernel - whatever version it will be.
I just like to have simple guidelines that I write down in my calendar, for example. For example: send myself an automatic reminder by e-mail every 6 months, reminding me to check for available Liquorix kernels. And if one day version 7.5 or so was the latest, I would then upgrade to 7.3 or something. Always about 2 versions below the latest version to ensure some stability.

These are all very simplistic thoughts from someone who finds the subject of kernel security updates difficult to understand. It seems to be very complex and dependent on countless factors that can change constantly.

[CharlesV]

You could install the liquorix meta package ( MX Package Installer - Popular Applications and then under kernels Liquorix 64 bit ( Or just search for liquorix and you will find it.)

This will keep your liquorix kernel updated as updates become available - however, it also means you will be on the latest as they arrive. ( For many people that is great, but I prefer to hang back and wait a bit - even on the older liquorix kernels. I run several machines that I am on daily, so one typically has 'nearly the latest' on board as a test - and then when I am satisfied with it, I update to the others.)

I have several clients that I maintain their machines on a monthly basis, and for them I use the latest kernel *older* than a month out. This also seems to work pretty well.

[debianix]

I have several clients that I maintain their machines on a monthly basis, and for them I use the latest kernel *older* than a month out. This also seems to work pretty well.

Thank you for ur help!

Do I understand correctly that you always use the Liquorix kernel for your clients, which has already been released for at least a month, and therefore hopefully the biggest problems have already been fixed?

If so, could I make it so that I imagine I'm one of your clients, and I set myself a reminder to check MXPI every month or every 60 days, and always take the kernel that is 2 versions away from the latest one?
Then I would only have to decide whether I prefer the Liquorix or the Debian kernel. The latest Debian kernel in MXPI is currently 6.6.11, and the Debian kernels seem to get new versions much less frequently. Given my hardware, would you consider it sensible to check the available kernels every 3 months, i.e. 4 times a year, and then take the second or third most recent kernel that is currently available? I suppose, since Debian is one of the most conservative distributions in terms of updates, that might be more appropriate for my use case? Stability is more important to me than anything else, but I would also like to have a certain minimum level of hardware support, because spending money on the latest hardware and then running it with an outdated kernel in the sense of a bottleneck doesn't seem good to me either.

[CharlesV]

There are three components in this area that are going to affect you:
1) Linux Kernel
2) Linux-firmware
3) Drivers that are not covered by the above two

Typically, kernels bring support in for many items, however, the linux-firmware is also important to keep up with as bugs and some issues are resolved there too. MX Keeps this upgrade to a degree, but your never 'on the latest' that I have seen. Most of the time I think this is very good, but if your attempting to keep your machine truly updated, then this is a component that you should address too. ( or just make sure you have the ahs repo turned on and wait for them to bring these in .)

Personally, with your machine age being young, and knowing gigabit (I run many gigabit motherboards), I think the right kernel for you in a liquorix, and yes keeping it around 2 or 3 versions behind is typically perfect. Now, also realize, the current liquorix is running on 6.9.x ... and has appeared to have some issues. ( The 6.8 has a few too), so this is why many of us says to try a 6.5 or 6.6 which have been very stable. )

I typically keep an eye on how many issues there are on a later kernel, and then I have test rigs that I push to see if I can get them to act up. ***then*** I make a decision about if I want to upgrade those or not. For me, yes, I typically try to update them.

For my clients, it really depends. I make the following evaluations for them:
a) Are they "all over the internet" ( Email and web )
b) Are they having trouble with X or Y
c) Is their machine new enough to handle / be better, with a newer kernel
d) is the kernel they are now on... dangerous ( as far as security issues )

If there is a yes to any of the above, then I update them ***in their kernel*** ( ie 6.6.10 to 6.6.11 or 6.5.6 to 6.5.9 etc ) . If the answer to C above is yes, then I will plan on a major version update on the next large update for them. ( ie take them to 6.9. )

I personally for your machine would say to move up when your ready on the major kernel version, and be cognizant of moving to a major version every X months. (and not on the latest one. )

[Snod Blatter]

Have you run the "sensors-detect" script in the terminal? I've had to do this on every machine I've ever installed Linux on, for some reason only a few sensors are detected on installation.

I like to use Psensor for hardware monitoring, you can set alarms for each sensor if you want to. It doesn't let you set fan speeds or anything though.

[debianix]

okay, thank you very much for all ur help!
I think I am ready to upgrade now.
The last question would be though:
What about taking the Kernel from Debian backports? This is 6.7.12 right now. I have no idea how often they upgrade it, but I assume that taking the Debian backport kernel now would be a quite safe choice, wouldnt it?

It's not that I'm too lazy to check the kernel versions and available updates every few months. But one of the biggest unique selling points for me with debian is that they choose their stuff, so one can rely on it for daily work and one doesnt have to think too much about stability or security issues.

If I now install the Debian kernel from the backports, it automatically gets an update via apt update/upgrade as soon as a new kernel version makes it into the Debian backports, right?

That would be attractive. Because then I would only have to install the backport kernel once and leave it alone. With the next major update, i.e. as soon as Debian trixie becomes stable, the next MX update wouldn't take long either, when the new stable kernel should be much more suitable for my hardware.

So I'm still wavering between: "Install Debian backport kernel and let it be",

and

"Install Liquorix kernel 6.6 and update to the latest Liquorix version minus 3 every 3 months".
For example: I look into the Kernel section in MXPI and see that the most recent liquorix kernel is 7.4.xx then I would calculate -3 major releases, what would be 7.1.xx for me to download..

I come closer to my goal and Im very close already, but well.. not so sure yet as u can see..

[siamhie]

What about taking the Kernel from Debian backports? This is 6.7.12 right now. I have no idea how often they upgrade it

FYI...The 6.7.x and 6.8.x line of kernels have reached end of life. Stick with the 6.6.x series as that one is an LTS (or long term supported until 2026) kernel.

From: Greg Kroah-Hartman <gregkh-AT-linuxfoundation.org>
To: linux-kernel-AT-vger.kernel.org, akpm-AT-linux-foundation.org, torvalds-AT-linux-foundation.org, stable-AT-vger.kernel.org
Subject: Linux 6.7.12
Date: Wed, 03 Apr 2024 15:16:01 +0200
Message-ID: <2024040316-sports-conceal-dbbb@gregkh>
Cc: lwn-AT-lwn.net, jslaby-AT-suse.cz, Greg Kroah-Hartman <gregkh-AT-linuxfoundation.org>
Archive-link: Article

Note, this is the LAST 6.7.y kernel to be released. This branch is now
end-of-life. Please move to the 6.8.y branch at this point in time.

Linux 6.8.12
From: Greg Kroah-Hartman
Date: Thu May 30 2024 - 03:59:26 EST

Next message: ranechita: "[PATCH v2] dt-bindings: iio: adc: add a7779 doc"
Previous message: Greg Kroah-Hartman: "Re: Linux 6.9.3"
Next in thread: Greg Kroah-Hartman: "Re: Linux 6.8.12"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Note, this the LAST 6.8.y release, this branch is now end-of-life. Please move
to the 6.9.y branch at this point in time.