Re: hwmon: nct6775: If an ACPI driver is available for this device, you should use it instead of the native driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/5/20 12:50 AM, Corentin Labbe wrote:
> Hello
> 
> I have a motherboard with a nct6775 and I got this on boot:
> nct6775: Found NCT6798D or compatible chip at 0x2e:0x290
> ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20200326/utaddress-204)
> ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
> And so the driver is not loaded.
> 
> Since I dont have an ACPI driver for it I have hacked the driver to skip this acpi_check_resource_conflict() and the driver works well:
> nct6798-isa-0290
> Adapter: ISA adapter
> in0:                   936.00 mV (min =  +0.00 V, max =  +1.74 V)
> in1:                     1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in2:                     3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in3:                     3.33 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in4:                     1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in5:                   776.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
> in6:                     1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in7:                     3.41 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in8:                     3.31 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in9:                   904.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
> in10:                  272.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
> in11:                  552.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
> in12:                    1.02 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in13:                    1.01 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
> in14:                  992.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
> fan1:                     0 RPM  (min =    0 RPM)
> fan2:                  1138 RPM  (min =    0 RPM)
> fan3:                  1744 RPM  (min =    0 RPM)
> fan4:                     0 RPM  (min =    0 RPM)
> fan5:                  2402 RPM  (min =    0 RPM)
> fan6:                     0 RPM  (min =    0 RPM)
> fan7:                     0 RPM  (min =    0 RPM)
> SYSTIN:                 +38.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
> CPUTIN:                 +37.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
> AUXTIN0:                +25.0°C    sensor = thermistor
> AUXTIN1:                +53.0°C    sensor = thermistor
> AUXTIN2:                +20.0°C    sensor = thermistor
> AUXTIN3:                +26.0°C    sensor = thermistor
> SMBUSMASTER 1:          +61.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
> 
> I got the same problem with an it87 and did the same, but does it exists a better way to do this ?
> Or does I ignore soemthing to make it works ?
> 


You could add "acpi_enforce_resources=lax" to the kernel command line.
Your hack (and the command line parameter) may be problematic
if ACPI does indeed access the chip since the chip has multiple pages
and ACPI may (unsynchronized with the kernel driver) change the page
number.

Worst case this may cause a system hang or reboot, unfortunately.
You might at least want to decode the ACPI tables to determine what,
if anything, it does when accessing the chip. You might be lucky
and it doesn't really access it - some systems just reserve the address
space but don't use it, presumably because system vendors don't want
users to access the SuperIO chip directly.

Guenter



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux