Bug 1239216 - in5 max will not set correctly
Summary: in5 max will not set correctly
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-04 13:32 UTC by John Griffiths
Modified: 2017-08-08 11:59 UTC (History)
11 users (show)

Fixed In Version: 3.4.0-3.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-08 11:59:57 UTC


Attachments (Terms of Use)
definition of chip "nct6779-isa-0290" (968 bytes, text/plain)
2015-07-04 13:32 UTC, John Griffiths
no flags Details
/etc/sensors3.conf (9.95 KB, text/plain)
2015-08-05 14:52 UTC, John Griffiths
no flags Details
sensors.gz (19.82 KB, application/x-gzip)
2015-08-18 18:36 UTC, Jaromír Cápík
no flags Details
Output of test binary sensors (4.22 KB, text/plain)
2015-08-18 19:24 UTC, John Griffiths
no flags Details
sensors-debug2.tgz (88.30 KB, application/x-gzip)
2015-08-19 12:13 UTC, Jaromír Cápík
no flags Details
Output of test binary sensors for debug 2 (12.48 KB, text/plain)
2015-08-19 15:43 UTC, John Griffiths
no flags Details
sensors-debug3.tgz (77.29 KB, application/x-gzip)
2015-08-19 16:39 UTC, Jaromír Cápík
no flags Details
Output of test binary sensors for debug 3 (32.34 KB, text/plain)
2015-08-19 17:43 UTC, John Griffiths
no flags Details

Description John Griffiths 2015-07-04 13:32:06 UTC
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?

Comment 1 John Griffiths 2015-07-04 13:35:33 UTC
Disregard "As an additional issue, how do I set limits for SYSTIN?". Got it. sensors -u. Duh

Comment 2 Jaromír Cápík 2015-08-04 16:47:55 UTC
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.

Comment 3 Jaromír Cápík 2015-08-05 12:22:44 UTC
Hello John.

Could you please attach your /etc/sensors3.conf ?

Thanks,
J.

Comment 4 John Griffiths 2015-08-05 14:52:14 UTC
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.

Comment 5 Jaromír Cápík 2015-08-13 18:26:05 UTC
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.

Comment 6 John Griffiths 2015-08-13 19:42:52 UTC
Where is the "noreplace" flag?

Comment 7 Jaromír Cápík 2015-08-14 11:40:48 UTC
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.

Comment 8 Jaromír Cápík 2015-08-18 17:53:19 UTC
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.

Comment 9 Jaromír Cápík 2015-08-18 18:36:48 UTC
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.

Comment 10 John Griffiths 2015-08-18 19:24:48 UTC
Created attachment 1064431 [details]
Output of test binary sensors

Hi Jaromír,

Here is the output.

Comment 11 Jaromír Cápík 2015-08-19 12:03:27 UTC
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.

Comment 12 Jaromír Cápík 2015-08-19 12:13:56 UTC
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.

Comment 13 John Griffiths 2015-08-19 15:43:29 UTC
Created attachment 1064920 [details]
Output of test binary sensors for debug 2

Comment 14 Jaromír Cápík 2015-08-19 16:27:23 UTC
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.

Comment 15 Jaromír Cápík 2015-08-19 16:39:41 UTC
Created attachment 1064928 [details]
sensors-debug3.tgz

Please, repeat the procedure with the following tarball...

md5sum:   965f52e20e2336c5a6790cb9800ca6f7  sensors-debug3.tgz

Comment 16 Jaromír Cápík 2015-08-19 16:47:36 UTC
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.

Comment 17 Jaromír Cápík 2015-08-19 16:48:53 UTC
The debug3 output should confirm my findings.

Comment 18 John Griffiths 2015-08-19 17:43:08 UTC
Created attachment 1064937 [details]
Output of test binary sensors for debug 3

Thank you Jaromír.

Comment 19 Jaromír Cápík 2015-08-20 11:09:09 UTC
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.

Comment 20 Jaromír Cápík 2015-08-20 11:17:09 UTC
Sorry, for some reason I opened the old file twice ... attached is the correct one.

Comment 21 Jaromír Cápík 2015-08-20 11:28:52 UTC
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.

Comment 22 John Griffiths 2015-08-20 14:08:42 UTC
904
1016
1104
1800
2040
2040

Comment 23 Jaromír Cápík 2015-08-20 15:02:42 UTC
(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.

Comment 24 Fedora Update System 2015-08-20 18:35:30 UTC
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

Comment 25 John Griffiths 2015-08-21 13:30:33 UTC
Hope it will be pushed to Fedora 22 as well.

Comment 26 Jaromír Cápík 2015-08-21 14:04:55 UTC
The above was just the 'noreplace' removal. It doesn't fix your issue.

Comment 27 Fedora Update System 2015-08-22 16:25:19 UTC
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

Comment 28 Fedora Update System 2015-08-28 17:36:18 UTC
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.

Comment 29 Justin M. Forbes 2015-10-20 19:34:42 UTC
*********** 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.

Comment 30 John Griffiths 2015-10-20 19:43:46 UTC
This is still occurring.

Comment 31 Fedora End Of Life 2016-07-19 20:11:06 UTC
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.

Comment 32 John Griffiths 2016-07-25 15:35:16 UTC
This is still occurring in Fedora 24.

Comment 33 Laura Abbott 2016-09-23 19:11:08 UTC
*********** 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.

Comment 34 John Griffiths 2016-09-24 12:11:12 UTC
Still happening in 4.7.3-200.fc24.x86_64

Comment 35 Justin M. Forbes 2017-04-11 14:53:55 UTC
*********** 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.

Comment 36 Justin M. Forbes 2017-04-28 17:13:21 UTC
*********** 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.

Comment 37 John Griffiths 2017-04-28 17:56:56 UTC
Still experiencing same error. Output is identical in new kernel.

Comment 38 Fedora End Of Life 2017-07-25 18:58:58 UTC
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.

Comment 39 Fedora End Of Life 2017-08-08 11:59:57 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.