Bug 162788

Summary: asus_acpi driver misbehaving in all Fedora Core 4 kernels.
Product: [Fedora] Fedora Reporter: Jean-Christophe Choisy <jc.choisy>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-30 01:37:36 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:
Bug Depends On:    
Bug Blocks: 165150    

Description Jean-Christophe Choisy 2005-07-08 17:26:57 UTC
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 18:51:16 UTC
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 22:18:12 UTC
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 23:18:04 UTC
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 21:52:36 UTC
[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.