Bug 494938 - IO resource conflict between ACPI and w83627ehf module
IO resource conflict between ACPI and w83627ehf module
Product: Fedora
Classification: Fedora
Component: lm_sensors (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-08 15:04 EDT by Markus B.
Modified: 2015-03-04 20:20 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-04-10 04:45:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dsdt.dsl (179.28 KB, text/plain)
2009-04-08 15:05 EDT, Markus B.
no flags Details
dmesg (34.79 KB, text/plain)
2009-04-08 15:05 EDT, Markus B.
no flags Details
dmidecode (8.07 KB, text/plain)
2009-04-08 15:06 EDT, Markus B.
no flags Details

  None (edit)
Description Markus B. 2009-04-08 15:04:26 EDT
Description of problem:
The w83627ehf module does not load due to a IO resource conflict with ACPI.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
# modprobe w83627ehf
Actual results:
w83627ehf: Found W83627EHG chip at 0x290
ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region SEN1 [0x295-0x296]
ACPI: Device needs an ACPI driver

Expected results:
The module should load.

Additional info:
I've attached the disassembled ACPI DSDT. The conflicting IO resource seems to be the fan device. Unfortunately the ACPI fan module is builtin and thus can not be deactivated.

The ACPI fan driver does only report the fan state, but the w83627ehf module/chip provides sophisticated hardware fan control, so I would prefer the w83627ehf driver to the ACPI fan driver.

Fedora 10 does not report any error and loads the module despite the resource conflict, which seems to work flawlessly.
Comment 1 Markus B. 2009-04-08 15:05:36 EDT
Created attachment 338777 [details]
Comment 2 Markus B. 2009-04-08 15:05:57 EDT
Created attachment 338778 [details]
Comment 3 Markus B. 2009-04-08 15:06:25 EDT
Created attachment 338779 [details]
Comment 4 Markus B. 2009-04-09 09:59:31 EDT
Adding "acpi_enforce_resources=lax" to the kernel boot parameters works as a
Comment 5 Hans de Goede 2009-04-10 04:45:48 EDT

Thanks for the bugreport. Recent kernels have changed the acpi_enforce_resources default from lax to strict. This was done deliberately knowing it may cause issues
like the one you are seeing, as it fixes much much worse (real) bugs.

The problem is that the ACPI code in your BIOS (which is active not only during
but also after boot), claims to (and probably does)  access the w83627ehf. Banging
IO ports of a chip from 2 different drivers, the Linux hwmon driver and the
ACPI code is a *really* bad idea and can cause all sort of issues (including
things like changing CPU / RAM voltage or clock speed).

So the old default of only issue a warning and hoping that the ACPI code
and the hwmon driver do not conflict and cause issues, was a bad idea.

As you've discovered yourself (and if you're willing to take the risk) you
can restore the old behaviour by passing acpi_enforce_resources=lax as
kernel boot parameter.

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