Bug 123681

Summary: Gnome battery applet doesn't work with acpi-enabled kernel
Product: [Fedora] Fedora Reporter: Darryl Dixon <bugzilla-fedora.20.esrever_otua>
Component: acpidAssignee: Bill Nottingham <notting>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: barryn, camilo, markmc, rvokal
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-01-28 22:35:59 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:

Description Darryl Dixon 2004-05-19 23:31:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
IBM R40 laptop with FC1 the gnome battery applet on the panel works
correctly (reports charge, power connection, etc)
Upgrade to FC2 with new 2.6 kernel which enables ACPI by default and
the Battery Charge Monitor fails on load with:
"""
Can't access ACPI events in /var/run/acpid.socket! Make sure the ACPI
subsystem is working and the acpid daemon is running.
"""
Additionally it then fails to show any charge in the battery or
respond to power/no power etc.  If the 2.6 kernel is booted with
acpi=off in the kernel command line the Battery Charge Monitor works
correctly again.

Version-Release number of selected component (if applicable):
gnome-applets-2.6.0-5

How reproducible:
Always

Steps to Reproduce:
1.Run FC1, Battery Charge Monitor works correctly
2.Upgrade to FC2 with 2.6 kernel, Battery Charge Monitor fails on load
3.Reboot with acpi=off with 2.6 kernel (or boot old 2.4 kernel) and
Battery Charge Monitor loads and works correctly
    

Actual Results:  Battery Charge Monitor non-functional (shows 0%
charge forever)

Expected Results:  Battery Charge Monitor reflects actual battery status

Additional info:

I assume this is because the applet uses APM, which is disabled by
ACPI on boot.

Comment 1 cam 2004-05-30 02:05:24 UTC
If applet settings are stored in a user directory, and a user
partition is restored from backup on a newly updated system, how does
the battstat applet recognise that APM has been replaced by ACPI?

I had trouble with ACPI not detecting my battery info, and when I
removed and reinstalled a battstat applet on the panel it chose the
wrong default suspend command (apm related one on an ACPI kernel)

Comment 2 Andrea Ferrandi 2004-07-21 06:54:24 UTC
The same happened to me.
In my case I understud that the acpid RPM was not installed on my
machine after the upgrade.
So I installed it from the first FC2 CD and now it works.

Comment 3 Mark McLoughlin 2004-07-21 15:31:40 UTC
Wrong suspend command issue is in bug #121061.

The issue with the applet working with ACPI on - i.e.:

"""
Can't access ACPI events in /var/run/acpid.socket! Make sure the ACPI
subsystem is working and the acpid daemon is running.
"""

has always turned out to be a problem with ACPI in any upstream report
I've seen. Moving to acpid.

Comment 4 Bill Nottingham 2004-07-21 15:38:15 UTC
Well, if acpid isn't running, there is the problem in bug 114443.

Comment 5 Bill Nottingham 2004-12-03 23:05:59 UTC
Is acpid running on machines that experience this?

Comment 6 Bill Nottingham 2005-01-28 22:35:59 UTC
Closing, no response.

If you get that message, it generally means that acpid isn't running.