Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

lm-sensors: How to tell what sensors-detect did??

Hi, in linux I ran sensors-detect, which I now learned is a potentially dangerous program. Fortunately I am 90% confident I accepted all of the defaults. I want to be completely sure. Is there a way to see what sensors-detect did and scanned for? Is there a way of viewing my "history" of sensors-detect and seeing my answers to the prompts?

Link to post
Share on other sites
5 minutes ago, jazzguitar1440 said:

Is there a way to see what sensors-detect did and scanned for?

You scrollback history.

 

6 minutes ago, jazzguitar1440 said:

Is there a way of viewing my "history" of sensors-detect and seeing my answers to the prompts?

AFAIK, no.

 

But don't worry, if you were to mess with anything that you shouldn't, it would crash instantly. If everything is running fine, then you have nothing to worry about.

FX6300 @ 4.2GHz | Gigabyte GA-78LMT-USB3 R2 | Hyper 212x | 3x 8GB + 1x 4GB @ 1600MHz | Gigabyte 2060 Super | Corsair CX650M | LG 43UK6520PSA
ASUS X550LN | i5 4210u | 12GB
Lenovo N23 Yoga

Link to post
Share on other sites

If you accepted the defaults, your probably fine. It can be harmful when it starts probing unknown devices, as it just starts sending common raw commands. The simplest way to tell is to restart your system and see if anything has stopped working or if the kernel is spamming a hardware error. "dmesg | grep error".

Link to post
Share on other sites
1 hour ago, Nayr438 said:

If you accepted the defaults, your probably fine. It can be harmful when it starts probing unknown devices, as it just starts sending common raw commands. The simplest way to tell is to restart your system and see if anything has stopped working or if the kernel is spamming a hardware error. "dmesg | grep error".

Ok I just got my pc and temperatures are spiking wildly. Temperatures go from 25C to 45C. This can happen when I open a new application or a new window. I have an Aorus Z490 motherboard. Is this temperature spiking possibly related to sensors-detect?

Link to post
Share on other sites
1 hour ago, Nayr438 said:

If you accepted the defaults, your probably fine. It can be harmful when it starts probing unknown devices, as it just starts sending common raw commands. The simplest way to tell is to restart your system and see if anything has stopped working or if the kernel is spamming a hardware error. "dmesg | grep error".

I ran dmesg | grep error and got

[    1.070673] pcieport DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
[    1.070949] pcieport  DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
[    3.148650] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro
[    3.280290] iwlwifi  Direct firmware load for iwlwifi-QuZ-a0-hr-b0-56.ucode failed with error -2
[    3.280304] iwlwifi  Direct firmware load for iwlwifi-QuZ-a0-hr-b0-55.ucode failed with error -2
[    3.280316] iwlwifi  Direct firmware load for iwlwifi-QuZ-a0-hr-b0-49.ucode failed with error -2
[    3.281340] iwlwifi  Direct firmware load for iwl-debug-yoyo.bin failed with error -2

 

Link to post
Share on other sites
2 hours ago, jazzguitar1440 said:
 

Ok I just got my pc and temperatures are spiking wildly. Temperatures go from 25C to 45C. This can happen when I open a new application or a new window. I have an Aorus Z490 motherboard. Is this temperature spiking possibly related to sensors-detect?

No, that would be entirely dependent on your cooling solution.

 

1 hour ago, jazzguitar1440 said:

[    1.070673] pcieport DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+
[    1.070949] pcieport  DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+

I am not sure what that is, but a search tells me that its just the kernel complaining about ownership. It can probably be ignored.

Adding "pcie_ports=dpc-native" to your kernel command-line may make that message disappear.

 

1 hour ago, jazzguitar1440 said:

[    3.148650] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro

This isn't an error, it can be ignored.

 

1 hour ago, jazzguitar1440 said:

[    3.280290] iwlwifi  Direct firmware load for iwlwifi-QuZ-a0-hr-b0-56.ucode failed with error -2

[    3.280304] iwlwifi  Direct firmware load for iwlwifi-QuZ-a0-hr-b0-55.ucode failed with error -2
[    3.280316] iwlwifi  Direct firmware load for iwlwifi-QuZ-a0-hr-b0-49.ucode failed with error -2
[    3.281340] iwlwifi  Direct firmware load for iwl-debug-yoyo.bin failed with error -2

 

Your missing the firmware file for your WiFi card. It's normally part of linux-firmware but your distro may be using a outdated pull.

 

You can try pulling the latest collection with

  • git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
  • cd linux-firmware
  • sudo make install

A kernel upgrade may or may not be necessary for full functionality however.

 

Link to post
Share on other sites

My two cents on the topic.

 

Whenever I ran it, I always said yes to every prompt and never had any issues, whether that was my laptop, my previous laptop, hardware from 2005, or hardware from 2014. If you stuck with the defaults, then there is no way that I can think of that anything could have gone south. If you said yes where the default is no, I'd be willing to bet that nothing was affected whatsoever.

Link to post
Share on other sites

Ok great. Does anyone know  Can I view what sensors-detect scanned for? At the end of running sensors detect I got a report, but I didn’t remember it. I want to see what sensors-detect scanned for and what it did. I also want to know the default temperature sensors out of the box that Lm-sensors recognize without having to run sensors-detect.

Link to post
Share on other sites

What are you specifically worried about? If your system works fine now, no damage was done.

 

Overall IMHO the dangers of running sensors-detect is a bit exaggerated sometimes. That being said, it can cause lock-ups, or at least in theory even data corruption or some similar problems. But these issues are somewhat theoretical, yes still there is some real risk. The more obscure, and more locked-in like the H/W you are using, the greater the risk - but I don't know about all the details. Blame manufacturers who don't  adhere to standards or open up their H/W sensors to software, for the whole issue of hw-sensors being as hairy as it is (not only in Linux)...

 

From sensors-detect man page:

 

Quote

DESCRIPTION
      sensors-detect is an interactive program that will walk you through the process of scanning your system for various hardware monitoring chips, or sensors, supported by libsen‐
      sors(3), or more generally by the lm_sensors tool suite.

      sensors-detect will look for the following devices, in order:

      •      Sensors embedded in CPUs, south bridges and memory controllers.

      •      Sensors embedded in Super I/O chips.

      •      Hardware monitoring chips accessed through ISA I/O ports.

      •      Hardware monitoring chips reachable over the SMBus or more generally any I2C bus on your system.

      As the last two detection steps can cause trouble on some systems, they are normally not attempted if the second detection step led to the discovery of a Super I/O  chip  with
      complete  hardware  monitoring  features.  However, the user is always free to ask for all detection steps if so is his/her wish. This can be useful if a given system has more
      than one hardware monitoring chip. Some vendors are known to do this, most notably Asus and Tyan.

OPTIONS
      --auto Run in automatic, non-interactive mode. Assume default answers to all questions. Note that this isn't necessarily safe as the internal logic  may  lead  to  potentially
             dangerous probes being attempted. See the WARNING section below.

WARNING
      sensors-detect  needs  to  access  the hardware for most of the chip detections.  By definition, it doesn't know which chips are there before it manages to identify them. This
      means that it can access chips in a way these chips do not like, causing problems ranging from SMBus lockup to permanent hardware damage (a rare case, thankfully.)

      The authors made their best to make the detection as safe as possible, and it turns out to work just fine in most cases, however it is impossible to guarantee that sensors-de‐
      tect  will  not lock or kill a specific system. So, as a rule of thumb, you should not run sensors-detect on production servers, and you should not run sensors-detect if can't
      afford replacing a random part of your system. Also, it is recommended to not force a detection step which would have been skipped by default, unless you know what you are do‐
      ing.

 

(this is not all of it, I copy+pasted the relevant part only)

 

This may be slightly different depending on your distribution, but generally lm_sensors suite hasn't changed much so your man page should be identical.

 

So we can not be sure what sensors-detect scanned for since it depends what you answer to it's questions.

 

However, we can see:

 

$ file $(which sensors-detect) 
/usr/bin/sensors-detect: Perl script text executable

So you could open the script and see what it does. The source of lm-sensors seems to be here, so anyone can take a look (there is no quarantee your distribution has the latest version of the script, though).

 

Depending on what you answered to the very last question of the script:

Do you want to overwrite /etc/conf.d/lm_sensors? (YES/no):

 

What it *detected* will be in /etc/conf.d/lm_sensors (or some other location in case your distribution has a different configuration compared to mine). The man page could be clearer on this, but this is all the script stores in the end (AFAIK; one could double-check from the documentation or the script itself). This file will contain kernel module names only. In case you did not tell it to write to the file, there is no way to know for sure what it scanned for. Actually, not even then since what the file contains is only those modules the script thinks your systems sensors needs. So best approach to answer the question would be to read the script or run it again (maybe answer "NO" to everything or at least the more dangerous probes at least on the first time, but on subsequent runs answer similarly you did on the first run).

 

You can see what  lm_sensors detects OOTB just by running sensors.

 

Hope this answers your questions. If it doesn't, and you still have some, please tell us your distribution (there might be some minute details on the packages of lm_sensors between distributions), and post here the contents of /etc/conf.d/lm_sensors, contents of /etc/sensors.d/* (contents of all files in there, if there are any), and output of the sensors command.

Edited by Wild Penquin
TYPO + few minor clarifications
Link to post
Share on other sites
9 hours ago, Wild Penquin said:

What are you specifically worried about? If your system works fine now, no damage was done.

 

Overall IMHO the dangers of running sensors-detect is a bit exaggerated sometimes. That being said, it can cause lock-ups, or at least in theory even data corruption or some similar problems. But these issues are somewhat theoretical, yes still there is some real risk. The more obscure, and more locked-in like the H/W you are using, the greater the risk - but I don't know about all the details. Blame manufacturers who don't  adhere to standards or open up their H/W sensors to software, for the whole issue of hw-sensors being as hairy as it is (not only in Linux)...

When it probes unknown devices, it sends common raw commands to see what a detected component returns. When it does this, it can lockup the device, place it in weird sleep states that can usually be recovered by removing power from the board (including cmos battery), wipe onboard components, or even send bad voltages across the board. The risk is real and damage does occur more often than people probably realize. MSI boards (I just see this one popup often) and Laptops are probably the most problematic. However the risk factor of it actually coming to that is fairly low, especially on hardware that's been out awhile, but its something you should still take caution with.

 

 

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Newegg

×