Bug 494938

Summary: IO resource conflict between ACPI and w83627ehf module
Product: [Fedora] Fedora Reporter: Markus B. <markusthe3rd>
Component: lm_sensorsAssignee: Phil Knirsch <pknirsch>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: hdegoede, pknirsch, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-10 08:45:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dsdt.dsl
none
dmesg
none
dmidecode none

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.