Bug 501596

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

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).

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.

(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.

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.

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.

(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).

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.

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.

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

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.