On 12/24/19 9:14 AM, PGNet Dev wrote:
On 12/24/19 8:29 AM, Guenter Roeck wrote:
The problem is - most likely - that the BIOS (or, rather, ACPI) accesses the
same memory range, and there is no synchronization. You could try to boot with
"acpi_enforce_resources=lax" command line option, but that would be on your
own risk, and some recent boards don't even boot if that command line option
is present.
You should not try to load the it87 driver on ASUS boards.
Did you try to load "asus_atk0110" ?
Had earlier come upon this,
Nuvoton nct6798d not detected #197
https://github.com/lm-sensors/lm-sensors/issues/197
re: the add'n of
acpi_enforce_resources=lax
and was just adding that to my grub kernel config.
just in case also added,
cat /etc/modules-load.d/sensors.conf
msr
k10temp
nct6775
+ asus_atk0110
now on reboot, I no longer see those^^ earlier conflict warnings; I _do_ see now,
...
[ 0.233419] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 2.484532] ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\AMW0.SHWM) (20190816/utaddress-204)
[ 2.489504] ACPI: This conflict may cause random problems and system instability
[ 2.492038] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 2.513650] asus_atk0110: Resources not safely usable due to acpi_enforce_resources kernel parameter
[ 2.540469] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9421164 (first instance was on PNP0C14:01)
[ 2.543119] acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9421164 (first instance was on PNP0C14:01)
[ 2.559449] ACPI: bus type USB registered
[ 13.553990] asus_atk0110: Resources not safely usable due to acpi_enforce_resources kernel parameter
[ 14.609097] acpi_cpufreq: overriding BIOS provided _PSD data
[ 14.610845] ACPI: Power Button [PWRB]
[ 14.611600] ACPI: Power Button [PWRF]
[ 14.633620] asus_atk0110: Resources not safely usable due to acpi_enforce_resources kernel parameter
[ 15.451860] asus_atk0110: Resources not safely usable due to acpi_enforce_resources kernel parameter
...
Seems `acpi_enforce_resources` and `asus_atk0110` don't play nicely?
AND, `sensors` certainly appears a bit more informative/useful!
sensors
k10temp-pci-00c3
Adapter: PCI adapter
Tdie: +55.2°C (high = +70.0°C)
Tctl: +55.2°C
nct6798-isa-0290
Adapter: ISA adapter
in0: 504.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.34 V (min = +0.00 V, max = +0.00 V) ALARM
in3: 3.34 V (min = +0.00 V, max = +0.00 V) ALARM
in4: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in5: 816.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.34 V (min = +0.00 V, max = +0.00 V) ALARM
in8: 3.25 V (min = +0.00 V, max = +0.00 V) ALARM
in9: 896.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in10: 408.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in11: 544.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: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM
in14: 1000.00 mV (min = +0.00 V, max = +0.00 V) ALARM
fan1: 1218 RPM (min = 0 RPM)
fan2: 1917 RPM (min = 0 RPM)
fan3: 905 RPM (min = 0 RPM)
fan4: 1190 RPM (min = 0 RPM)
fan5: 0 RPM (min = 0 RPM)
fan6: 0 RPM (min = 0 RPM)
fan7: 0 RPM (min = 0 RPM)
SYSTIN: +36.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
CPUTIN: +32.0°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor
AUXTIN0: +25.0°C sensor = thermistor
AUXTIN1: +36.0°C sensor = thermistor
AUXTIN2: +21.0°C sensor = thermistor
AUXTIN3: +26.0°C sensor = thermistor
PCH_CHIP_CPU_MAX_TEMP: +0.0°C
PCH_CHIP_TEMP: +0.0°C
PCH_CPU_TEMP: +0.0°C
PCH_MCH_TEMP: +0.0°C
intrusion0: ALARM
intrusion1: ALARM
beep_enable: disabled
, with ALL of those now available to desktop utils such as KDE's (slightly broken) ThermalMonitor plasma widget ... (need to figure out which of those are the CPU, vs Mobo, fan/temp sensors)
I don't know what, if any, issues are introducted by the use of `acpi_enforce_resources=lax` ...
This _is_ just a workaround, yes? I.e., BIOS still should have a fix?
The BIOS does exactly what the board vendor wants it to do: Reject direct access
to the Super-IO chip. The board vendor wants you to access the chip through ACPI,
ie with asus_atk0110. Unfortunately, it looks like the board vendor also
changed the ACPI data sufficiently enough to make that driver not work for
your board (assuming you tried loading it without acpi_enforce_resources=lax).
There is nothing we can do about that unless the board vendor provides the information
necessary to interpret the DSDT, or someone spends the time to reverse engineer it.
Guenter
