Bug 501596 - ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region HWRE [0x290-0x299]
ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region HWRE [0...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-19 17:30 EDT by Leszek Matok
Modified: 2010-06-28 08:36 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 08:36:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 12376 None None None Never
Linux Kernel 13571 None None None Never

  None (edit)
Description Leszek Matok 2009-05-19 17:30:37 EDT
After a yum upgrade to F11+updates (which went suspiciously smooth), my motherboard's sensors stopped being supported with this in dmesg:
w83627ehf: Found W83627DHG chip at 0x290
ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region HWRE [0x290-0x299]
ACPI: Device needs an ACPI driver

There is an "atk0110-acpi-0" adapter, it probes a small but rather sufficient subset of my sensors, but doesn't support PWM for fans, which is a serious regression for my ears (the motherboard doesn't allow me to set fan speed in BIOS).

This is with current kernel-PAE-2.6.29.3-140.fc11.i686

Used to work since around 2.6.20 until kernel-PAE-2.6.27.21-170.2.56.fc10.i686

Also works with kernel-PAE-2.6.30-0.81.rc5.git1.fc12.i686 from koji (but it oopsed somewhere in RAID code, so I went back to 2.6.29.3 out of fear). Here I have both atk0110 and w83627ehf adapters.

I've tried entering "acpi_enforce_resource=strict" on the kernel command line after reading http://bugzilla.kernel.org/show_bug.cgi?id=12376 but it didn't help.

Can I work around it somehow, or maybe it's possible to backport a fix? Or maybe 2.6.30 is planned to be pushed to F11?
Comment 1 Bug Zapper 2009-06-09 12:08:04 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Leszek Matok 2009-06-28 05:40:32 EDT
I went with 2.6.30-rc from Rawhide, with "dba_debug=off" to silence the oops.

I totally vote for 2.6.30 in F11 (there's a bit of pain with yum updates when you have multi-installable package in a version newer than newest update, on which something depends).
Comment 3 Patrick Mansfield 2009-07-16 00:52:43 EDT
Per this (closed) bug report:

     http://bugzilla.kernel.org/show_bug.cgi?id=13571

I booted with acpi_enforce_resources=lax, and got my old expected behavior back, but now I have both atk0110-acpi-0 and w83627ehf-isa-0290 show up in my sensors output.

So I should be able to control my fan speeds again.
Comment 4 Patrick Mansfield 2009-07-27 14:47:29 EDT
(In reply to comment #3)
> Per this (closed) bug report:
> 
>      http://bugzilla.kernel.org/show_bug.cgi?id=13571
> 
> I booted with acpi_enforce_resources=lax, and got my old expected behavior
> back, but now I have both atk0110-acpi-0 and w83627ehf-isa-0290 show up in my
> sensors output.
> 
> So I should be able to control my fan speeds again.  

Oh, the fan inputs show up for the atk0110, but under /sys/class/hwmon/hwmon0, not /sys/class/hwmon/hwmon0/device, maybe that's a bug (or the sensor detect is borken).

And, they can have different mappings. For example on my system, fan2 is the CPU fan under the w83627 driver, but it is fan1 under atk0110, like:

/sys/class/hwmon/hwmon1/device/fan2_input 
/sys/class/hwmon/hwmon0/fan1_input

I haven't tried to use them with fancontrol.

And, you can probably also block the asus_atk0110 module if you want to just use the w83627ehf one.
Comment 5 Leszek Matok 2009-08-08 11:38:02 EDT
Well, fan*_input lists the current fan speed in RPM and I can't write to it.

Using the w83627ehf driver I can control fan speed by writing to pwm*_enable and pwm* files. fancontrol does the same afaict and can't control fan speeds using asus_atk0110 module.

But yes, acpi_enforce_resources=lax helps and I'm now happily back on F11 2.6.29.
Comment 6 Jean Delvare 2009-09-07 04:48:15 EDT
I'll try to answers your questions.

Leszek, are you sure you can't set the fan speed using the BIOS? I thought that all recent Asus motherboards implemented "Q-Fan", which when enabled in the BIOS controls the fan speeds automatically. Which motherboard model do you have?

Patrick, it is strongly discouraged to load both an ACPI driver (asus_atk0110) and a native driver (w83627ehf) for the same hardware monitoring chip. On Asus motherboards which are supported by the asus_atk0110 driver, you should not use acpi_enforce_resources=lax so that the native driver will not load. Please read Hans' blog post for some more background:
http://hansdegoede.livejournal.com/7932.html

Patrick, it is OK for sysfs files to be either in /sys/class/hwmon/hwmon# or /sys/class/hwmon/hwmon#/device. This is supported by libsensors since version 3.0.2. The idea is that not all hwmon class device have a physical device in the sysfs tree. In particular, ACPI-backed implementations do not.

Patrick, I wasn't aware of the mapping difference between the asus_atk0110 driver output and the native driver output. But I am not surprised either. The native drivers use the hardware register order to number the inputs. The acpi_atk0110 driver follows what the ACPI implementation did, and maybe Asus tried to order the fan inputs in a consistent way for all their products.

I confirm that the asus_atk0110 driver currently can't control fan speeds. I don't know whether this will possibly be added in the future or not.
Comment 7 Patrick Mansfield 2009-09-07 13:40:45 EDT
(In reply to comment #6)

> Patrick, it is strongly discouraged to load both an ACPI driver (asus_atk0110)
> and a native driver (w83627ehf) for the same hardware monitoring chip. On Asus
> motherboards which are supported by the asus_atk0110 driver, you should not use
> acpi_enforce_resources=lax so that the native driver will not load. Please read
> Hans' blog post for some more background:
> http://hansdegoede.livejournal.com/7932.html

Yes, I understand that is generally wrong but had not changed it, since it has been working fine.

But I just tried booting without acpi_enforce_resources=lax and with blacklisting asus_atk0110, and it worked fine with 2.6.30.5-43.fc11.i686.PAE, though it failed with 2.6.29.6-217.2.16.fc11.i686.PAE, with the same conflict error:

ACPI: I/O resource w83627ehf [0x295-0x296] conflicts with ACPI region HWRE [0x290-0x299]

I didn't think expect the above failure, but again all is working fine.

> Patrick, it is OK for sysfs files to be either in /sys/class/hwmon/hwmon# or
> /sys/class/hwmon/hwmon#/device. This is supported by libsensors since version
> 3.0.2. The idea is that not all hwmon class device have a physical device in
> the sysfs tree. In particular, ACPI-backed implementations do not.

I don't think sensors-detect worked right, but I can't remember, I ended up manually setting values in fancontrol. Plus I don't know what version of lm_sensors I originally ran it with (note I'm currently using lm_sensors-3.1.0-1.fc11.i586).
Comment 8 Leszek Matok 2009-09-07 14:18:35 EDT
Jean,

Q-Fan works properly only for the CPU fan.

It does slow down other fans a bit, but only a little bit even in "silent" mode (like slowing to 90%, while I do 35%). This is an Asus P5B.

So yes, I am sure my BIOS lacks in this matter, but the software could overcome this limitation for 3 years, suddenly denying me the functionality. It's a regression and I'm certainly going to stay with acpi_enforce_resources=lax if a "whitelist" can't be configured.
Comment 9 Jean Delvare 2009-09-07 14:25:01 EDT
Patrick, sensors-detect doesn't know about asus_atk0110 driver yet. This is on our to-do list, but it isn't trivial because the ATK0110 device can't be reliably detected from user-space.

Laszek, Asus boards which work with the asus_atk0110 driver are never going to be whitelisted. If anything, we should improve this driver to provide the missing functionality. But I don't know if we can do this given the lack of documentation.
Comment 10 Bug Zapper 2010-04-27 10:24:37 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Bug Zapper 2010-06-28 08:36:51 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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