Bug 162788 - asus_acpi driver misbehaving in all Fedora Core 4 kernels.
asus_acpi driver misbehaving in all Fedora Core 4 kernels.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks: FCMETA_ACPI
  Show dependency treegraph
 
Reported: 2005-07-08 13:26 EDT by Jean-Christophe Choisy
Modified: 2015-01-04 17:20 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-29 21:37:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jean-Christophe Choisy 2005-07-08 13:26:57 EDT
Description of problem:
I'm using an Asus V6800V laptop with Fedora Core 4. When using the asus specific acpi buttons (like 
lcd on/off, or bluetooth switch) there's a huge lag of a few minutes. Which means for instance, the LCD 
will switch off only 2 minutes or so after I pressed the button. This doesn't happen on ubuntu's and 
debian's stock kernels, and on any kernel I've compiled myself before, only the fedora kernels do this to 
me, even the latest update. Those buttons are handled by the asus_acpi driver by the way.


Version-Release number of selected component (if applicable):
All currently released Fedora Core 4 kernels.


How reproducible:
Always

Steps to Reproduce:
1. Install any fedora 4 kernel on an asus V6800V (maybe others?)
2. Try to use the asus buttons to shut down the LCD for instance, or activate bluetooth, or lower 
brightness...
3.
  
Actual results:
Each button press only takes effect one or two minutes (!!) later

Expected results:
The button's action should be performed instantly, like with all other distros I've tried.

Additional info:
This is my only problem with fedora core 4, which is really a stunning product! Thanks for all the hard 
work...
Comment 1 Dave Jones 2005-07-08 14:51:16 EDT
This is very puzzling, as we don't change a single line of code from the
upstream driver.  The only thing I can think of is that this has regressed
upstream, and the kernels you tried from other distros are on earlier revisions.
Comment 2 Jean-Christophe Choisy 2005-07-08 18:18:12 EDT
I will try to see if anything interresting appears in the logs, but I've been running a 2.6.12.2 self compiled 
kernel on this very same notebook, and the asus acpi buttons were all working great. I'll try to see if the 
logs reveal something, but this is definitly a fedora kernel problem... Maybe something else is triggering 
this bug?
Comment 3 Dave Jones 2005-07-08 19:18:04 EDT
Possibly.  Since you're not adverse to building kernels, you may want to try
rebuilding the Fedora kernel with some of the patches disabled, to try and
narrow down the cause.

The biggest suspect is probably exec-shield.
Comment 4 Dave Jones 2005-07-15 17:52:36 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.

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