Bug 123681 - Gnome battery applet doesn't work with acpi-enabled kernel
Summary: Gnome battery applet doesn't work with acpi-enabled kernel
Alias: None
Product: Fedora
Classification: Fedora
Component: acpid   
(Show other bugs)
Version: 2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-19 23:31 UTC by Darryl Dixon
Modified: 2014-03-17 02:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-28 22:35:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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

How reproducible:

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.

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