Bug 494938 - IO resource conflict between ACPI and w83627ehf module
Summary: IO resource conflict between ACPI and w83627ehf module
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: lm_sensors
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-08 19:04 UTC by Markus B.
Modified: 2015-03-05 01:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-10 08:45:48 UTC
Type: ---
Embargoed:


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

Description Markus B. 2009-04-08 19:04:26 UTC
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):
-------------------------------------------------------------
lm_sensors-3.1.0-1.fc11

How reproducible:
-----------------
Always.

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 19:05:36 UTC
Created attachment 338777 [details]
dsdt.dsl

Comment 2 Markus B. 2009-04-08 19:05:57 UTC
Created attachment 338778 [details]
dmesg

Comment 3 Markus B. 2009-04-08 19:06:25 UTC
Created attachment 338779 [details]
dmidecode

Comment 4 Markus B. 2009-04-09 13:59:31 UTC
Adding "acpi_enforce_resources=lax" to the kernel boot parameters works as a
workaround.

Comment 5 Hans de Goede 2009-04-10 08:45:48 UTC
Markus,

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.