Created attachment 1046010 [details] definition of chip "nct6779-isa-0290" Description of problem: I created a file in /etc/sensors.d to set the min and max limits for a chip that in not defined, nct6779-isa-0290. All the min and max values set correctly for in0 - in14 except the max value for in5. Version-Release number of selected component (if applicable): lm_sensors-3.3.5-5.fc22.x86_64 How reproducible: always Steps to Reproduce: 1. create file to define limits for chip 2. run sensors -s 3. run sensors Actual results: acpitz-virtual-0 Adapter: Virtual device temp1: +27.8°C (crit = +106.0°C) temp2: +29.8°C (crit = +106.0°C) radeon-pci-0100 Adapter: PCI adapter temp1: +48.5°C (crit = +120.0°C, hyst = +90.0°C) coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +43.0°C (high = +85.0°C, crit = +105.0°C) Core 0: +42.0°C (high = +85.0°C, crit = +105.0°C) Core 1: +42.0°C (high = +85.0°C, crit = +105.0°C) Core 2: +40.0°C (high = +85.0°C, crit = +105.0°C) Core 3: +36.0°C (high = +85.0°C, crit = +105.0°C) nct6779-isa-0290 Adapter: ISA adapter in0: +1.05 V (min = +0.90 V, max = +1.10 V) in1: +1.03 V (min = +0.90 V, max = +1.10 V) in2: +3.38 V (min = +2.98 V, max = +3.63 V) in3: +3.38 V (min = +2.98 V, max = +3.63 V) in4: +1.02 V (min = +0.90 V, max = +1.10 V) in5: +2.04 V (min = +1.80 V, max = +2.04 V) ALARM in6: +1.49 V (min = +1.35 V, max = +1.65 V) in7: +3.39 V (min = +2.98 V, max = +3.63 V) in8: +3.33 V (min = +2.98 V, max = +3.63 V) in9: +1.06 V (min = +0.90 V, max = +1.10 V) in10: +1.49 V (min = +1.35 V, max = +1.65 V) in11: +1.49 V (min = +1.35 V, max = +1.65 V) in12: +0.26 V (min = +0.22 V, max = +0.27 V) in13: +0.20 V (min = +0.18 V, max = +0.22 V) in14: +1.49 V (min = +1.35 V, max = +1.65 V) fan1: 779 RPM (min = 0 RPM) fan2: 1465 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +40.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor CPUTIN: +0.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +0.0°C sensor = thermistor AUXTIN1: +0.0°C sensor = thermistor AUXTIN2: +0.0°C sensor = thermistor AUXTIN3: +0.0°C sensor = thermistor PECI Agent 0: +36.5°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 Expected results: acpitz-virtual-0 Adapter: Virtual device temp1: +27.8°C (crit = +106.0°C) temp2: +29.8°C (crit = +106.0°C) radeon-pci-0100 Adapter: PCI adapter temp1: +48.5°C (crit = +120.0°C, hyst = +90.0°C) coretemp-isa-0000 Adapter: ISA adapter Physical id 0: +43.0°C (high = +85.0°C, crit = +105.0°C) Core 0: +42.0°C (high = +85.0°C, crit = +105.0°C) Core 1: +42.0°C (high = +85.0°C, crit = +105.0°C) Core 2: +40.0°C (high = +85.0°C, crit = +105.0°C) Core 3: +36.0°C (high = +85.0°C, crit = +105.0°C) nct6779-isa-0290 Adapter: ISA adapter in0: +1.05 V (min = +0.90 V, max = +1.10 V) in1: +1.03 V (min = +0.90 V, max = +1.10 V) in2: +3.38 V (min = +2.98 V, max = +3.63 V) in3: +3.38 V (min = +2.98 V, max = +3.63 V) in4: +1.02 V (min = +0.90 V, max = +1.10 V) in5: +2.04 V (min = +1.80 V, max = +2.20 V) in6: +1.49 V (min = +1.35 V, max = +1.65 V) in7: +3.39 V (min = +2.98 V, max = +3.63 V) in8: +3.33 V (min = +2.98 V, max = +3.63 V) in9: +1.06 V (min = +0.90 V, max = +1.10 V) in10: +1.49 V (min = +1.35 V, max = +1.65 V) in11: +1.49 V (min = +1.35 V, max = +1.65 V) in12: +0.26 V (min = +0.22 V, max = +0.27 V) in13: +0.20 V (min = +0.18 V, max = +0.22 V) in14: +1.49 V (min = +1.35 V, max = +1.65 V) fan1: 779 RPM (min = 0 RPM) fan2: 1465 RPM (min = 0 RPM) fan3: 0 RPM (min = 0 RPM) fan4: 0 RPM (min = 0 RPM) fan5: 0 RPM (min = 0 RPM) SYSTIN: +40.0°C (high = +0.0°C, hyst = +0.0°C) ALARM sensor = thermistor CPUTIN: +0.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +0.0°C sensor = thermistor AUXTIN1: +0.0°C sensor = thermistor AUXTIN2: +0.0°C sensor = thermistor AUXTIN3: +0.0°C sensor = thermistor PECI Agent 0: +36.5°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 Additional info: As an additional issue, how do I set limits for SYSTIN?
Disregard "As an additional issue, how do I set limits for SYSTIN?". Got it. sensors -u. Duh
Hello John. I'm curious, whether that could be some kind of conflict with the "nct6779-*" catchall config. Gonna look at that closer. Regards, Jaromir.
Hello John. Could you please attach your /etc/sensors3.conf ? Thanks, J.
Created attachment 1059491 [details] /etc/sensors3.conf I made no changes to file. It is as installed from lm_sensors-3.3.5-6.fc22.x86_64.
Well, it's marked as config(noreplace) and therefore your version could be much older. I was thinking about removing the noreplace flag, since we create /etc/sensors.d now.
Where is the "noreplace" flag?
In the RPM spec ... %config(noreplace) %{_sysconfdir}/sensors3.conf This tells RPM to preserve the file if exists. That means updates won't change it. But I consider this a potential cause of issues and gonna remove the noreplace flag so that users get the latest config with each update. Customizations can always bedone in /etc/sensors.d, but first we need to test that to learn how it behaves and what priorities the config files have.
Hello John. I analysed the code and unfortunately the configuration is processed based on the detected sensors and the troubleshooting needs to be done directly on the affected hardware. Are you willing to install custom debug RPMs? It would be faster if you could connect to one of the Fedora IRC channels (fedora-devel) so that we could communicate on-line and debug faster. Right now it looks like a memory corruption bug and such bugs are tough. Please, let me know.
Created attachment 1064393 [details] sensors.gz I'm attaching the first debug executable (gzipped) ... md5sum: 20e360f6c1517c21c9cc7d7d7a36c725 sensors.gz If you're willing to test the binary, then download it to a temporary location, then unzip ... gzip -d sensors.gz ... then set the executable bit ... chmod +x sensors ... and execute with redirecting the output to a text file ... ./sensors > sensors-debug1.txt Once done, attach the resulting file, please.
Created attachment 1064431 [details] Output of test binary sensors Hi Jaromír, Here is the output.
Thanks, that means the value had already been overwritten when processed with the get_sensor_limit_data call. I'll produce one more debug package with even more verbosity level shortly.
Created attachment 1064811 [details] sensors-debug2.tgz The attached tarball contains more verbose debug binaries. This time I had to include the libsensors library and tweak the LD_LIBRARY_PATH so that the executable calls the debug functions in the library. md5sum: b89c2452c11634253d045a90bbb5fe77 sensors-debug2.tgz Please, download the tarball to a temporary location and untar ... tar xzf sensors-debug2.tgz ... then go to the sensors-debug2 directory and execute the RUN.sh script cd sensors-debug2 && ./RUN.sh It should produce a text file called sensors-debug2.txt. Please, attach it to this report.
Created attachment 1064920 [details] Output of test binary sensors for debug 2
Hmmmmmmm ... this is even more interesting. I expected the __sensors_get_value function to call sensors_eval_expr function for the multiplication in the config, but according to the debug output, that didn't happen. According to the output the expression is not considered to be an expression, but for some reason majority of the values are evaluated correctly. The code must contain some historical leftovers and that makes the whole analysis more difficult.
Created attachment 1064928 [details] sensors-debug3.tgz Please, repeat the procedure with the following tarball... md5sum: 965f52e20e2336c5a6790cb9800ca6f7 sensors-debug3.tgz
I think I know where the problem is. It seems your limits defined in the config file you created are completely ignored and taken from the kernel interface instead. And for some reason the subfeature 27, that brings the maximum value for the in5 input has a bug (in the kernel) and returns the same value like subfeature 25.
The debug3 output should confirm my findings.
Created attachment 1064937 [details] Output of test binary sensors for debug 3 Thank you Jaromír.
Hello John. This was probably a misunderstanding. I forgot to tell you that you need to change the path to sensors-debug3. The output provided is from the sensors-debug2 tarball. So, here's the right procedure ... tar xzf sensors-debug3.tgz cd sensors-debug3 && ./RUN.sh It should produce sensors-debug3.txt and that's the file I'm interested in.
Sorry, for some reason I opened the old file twice ... attached is the correct one.
According to the following part of the output, the wrong limit is very probably taken directly from the /sys/class/hwmon/hwmon4/in5_max file: ----------------------------- in5: [DEBUG:get_val:subfeat=25][DEBUG:read_sysfs_attr:n=/sys/class/hwmon/hwmon4/in5_input][DEBUG:read_sysfs_attr:value1=2040.000000][DEBUG:read_sysfs_attr:value2=2.040000][DEBUG:get_val:result1=2.040000] +2.04 V [DEBUG:get_val:subfeat=28][DEBUG:read_sysfs_attr:n=/sys/class/hwmon/hwmon4/in5_alarm][DEBUG:read_sysfs_attr:value1=1.000000][DEBUG:read_sysfs_attr:value2=1.000000][DEBUG:get_val:result1=1.000000][DEBUG:get_val:subfeat=26][DEBUG:read_sysfs_attr:n=/sys/class/hwmon/hwmon4/in5_min][DEBUG:read_sysfs_attr:value1=1800.000000][DEBUG:read_sysfs_attr:value2=1.800000][DEBUG:get_val:result1=1.800000][DEBUG:lim_val=1.800000;lim_name=min][DEBUG:get_val:subfeat=27][DEBUG:read_sysfs_attr:n=/sys/class/hwmon/hwmon4/in5_max][DEBUG:read_sysfs_attr:value1=2040.000000][DEBUG:read_sysfs_attr:value2=2.040000][DEBUG:get_val:result1=2.040000][DEBUG:lim_val=2.040000;lim_name=max](min = +1.80 V, max = +2.04 V) ALARM ----------------------------- I'd like to ask you to confirm that by typing the file content directly together with the content of other similar files: cat /sys/class/hwmon/hwmon4/in{4,5}_{min,input,max} Please, copy'n'paste the output to this report.
904 1016 1104 1800 2040 2040
(In reply to John Griffiths from comment #22) > 904 > 1016 > 1104 > 1800 > 2040 > 2040 Thanks John. The last two lines confirm my suspicion. The /sys/class/hwmon/hwmon4/in5_max file returns wrong value. Instead of the max limit it returns the same value like the in5_input. I've already switched this to kernel. I believe it's some typo in the indexing, etc.
lm_sensors-3.4.0-3.fc23 has been submitted as an update to Fedora 23. https://bugzilla.redhat.com/show_bug.cgi?id=1239216
Hope it will be pushed to Fedora 22 as well.
The above was just the 'noreplace' removal. It doesn't fix your issue.
lm_sensors-3.4.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update lm_sensors'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-13840
lm_sensors-3.4.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
This is still occurring.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still occurring in Fedora 24.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 24 has now been rebased to 4.7.4-200.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 25, and are still experiencing this issue, please change the version to Fedora 25. If you experience different issues, please open a new bug report for those.
Still happening in 4.7.3-200.fc24.x86_64
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Still experiencing same error. Output is identical in new kernel.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.