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.
Created attachment 338777 [details] dsdt.dsl
Created attachment 338778 [details] dmesg
Created attachment 338779 [details] dmidecode
Adding "acpi_enforce_resources=lax" to the kernel boot parameters works as a workaround.
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.