Bug 23812 - HAL does not provide battery information on RHEL5 and CentOS-5
HAL does not provide battery information on RHEL5 and CentOS-5
Status: CLOSED DOCUMENTED
Product: ACPI
Classification: Unclassified
Component: Power-Battery
All Linux
: P1 normal
Assigned To: Lan Tianyu
http://elrepo.org/bugs/view.php?id=91
:
Depends on:
Blocks: 16444
  Show dependency treegraph
 
Reported: 2010-11-26 18:08 UTC by Dag Wieers
Modified: 2013-04-13 03:29 UTC (History)
8 users (show)

See Also:
Kernel Version: 3.2
Tree: Mainline
Regression: Yes


Attachments
Requested "grep . /proc/acpi/battery/*/*" and extras. (1.48 KB, text/plain)
2010-12-15 17:16 UTC, Alan Bartlett
Details
Repeated test result using linux-2.6.37 (1.46 KB, text/plain)
2011-01-08 19:10 UTC, Alan Bartlett
Details
Repeated test results, using linux-2.6.38.2 (1.56 KB, text/plain)
2011-03-30 15:12 UTC, Alan Bartlett
Details
Repeated test results, using linux-3.2.1 (2.51 KB, text/plain)
2012-01-23 17:37 UTC, Alan Bartlett
Details

Description Dag Wieers 2010-11-26 18:08:40 UTC
On LWN I was requested to report the following regression.

Due to the cleanup of various /proc/acpi entries from the 2.6.36 kernel (notable /proc/acpi/info) RHEL5's HAL daemon (Hardware Abstraction Layer) does not provide ACPI power_management information. Because of this, the Gnome Power Manager fails to report any battery status, despite the fact that other applications, using sysfs, do not seem to be affected (KDE, dstat, acpi, ...) You can verify this using:

    lshal | grep battery
or
    lshal | grep power_management
or
    hal-device-manager


More information about the change that caused this issue is available from:

    http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commitdiff;h=2245ba2a3a975656bb303dfaa115accaa4667083;hp=e2e96c663639a3361bb1a84e666887d308c6c87e

The ELRepo project provides mainline kernels for RHEL5 and CentOS-5 both for people to test their hardware on recent kernels (so we can backport them), as well as using these kernels for reporting regressions upstream.
Comment 1 Len Brown 2010-11-30 03:01:45 UTC
is there a newer version of HAL that talks to /sys/class/power_supply?
Comment 2 Dag Wieers 2010-11-30 08:10:36 UTC
Very likely, since there's no major outcry ;-) But no update from Red Hat as they do not ship anything newer than 2.6.18 themselves (and Gnome 2.16) in RHEL5. So for RHEL5/CentOS-5 users updating a component like that is not without risk and not recommended.

The thread on LWN is this: https://lwn.net/Articles/417243/ and I was requested to report these as regressions.
Comment 3 Len Brown 2010-12-07 02:34:03 UTC
Dag,
Do I understand that you have since moved to RHEL 6,
and so this is (personally) no longer a problem for you?
Comment 4 Dag Wieers 2010-12-07 11:42:13 UTC
Not for my main laptop, but it's a problem on another system, and makes our kernel-ml offering for RHEL5/CentOS-5 less useful for other (desktop) users.

The main reason for reporting it is because it appeared we were helping to kernel developers by reporting regressions. If however the decision is to not fix this, then I accept that policy and we won't be reporting those regressions in the future.

In that case Linus' "The rule is that you don't break userspace. It's a very simple rule to understand." needs a small update :-)
Comment 5 Len Brown 2010-12-14 02:53:12 UTC
/sys/class/power_supply went upstream in 2.6.23, in 2007.

The ACPI battery driver added /sys/class/power_supply in 2.6.24 in 2007.

We announced that /proc/acpi/was going away in 2007
via Documentation/feature-removal.txt

In 2.6.37.y, we set CONFIG_ACPI_PROCFS_POWER=n by default.
If you still want to use that I/F, now you need to set
CONFIG_ACPI_PROCFS_POWER=y.

Please re-open if that doesn't work.

We will add a run time warning that this code
is scheduled to be deleted entirely.  yes, we try
to maintain compatibility with the installed user-space,
but there are limits to how old a user-space that
it makes sense for the upstream kernel to support.
Comment 6 Alan Bartlett 2010-12-14 15:30:51 UTC
[ajb@stxsl ~]$ grep CONFIG_ACPI_PROCFS_POWER /boot/config*
/boot/config-2.6.35-9.el5.elrepo:CONFIG_ACPI_PROCFS_POWER=y
/boot/config-2.6.36-2.el5.elrepo:CONFIG_ACPI_PROCFS_POWER=y

Len,

Would you please clarify for me -- are you saying that in 2.6.37.y this interface will again work correctly?

Currently: 

2.6.35.y O.k.
2.6.36.y Not O.k.

Alan.
Comment 7 Zhang Rui 2010-12-15 00:47:30 UTC
> /boot/config-2.6.36-2.el5.elrepo:CONFIG_ACPI_PROCFS_POWER=y

in 2.6.36.y, please attach the output of "grep . /proc/acpi/battery/*/*"
Comment 8 Alan Bartlett 2010-12-15 17:16:39 UTC
Created attachment 40232 [details]
Requested "grep . /proc/acpi/battery/*/*" and extras.

The output produced from "uname -rm", "grep CONFIG_ACPI_PROCFS_POWER /boot/config-$(uname -r)" and "grep . /proc/acpi/battery/*/*" for 2.6.36.2

Please note that the above output is identical to that produced on 2.6.35.9 (when the kernel SUBLEVELs and EXTRAVERSIONs in the output are disregarded).
Comment 9 Alan Bartlett 2010-12-15 23:59:33 UTC
(In reply to comment #5)
> /sys/class/power_supply went upstream in 2.6.23, in 2007.
> 
> The ACPI battery driver added /sys/class/power_supply in 2.6.24 in 2007.
> 
> We announced that /proc/acpi/was going away in 2007
> via Documentation/feature-removal.txt
> 
> In 2.6.37.y, we set CONFIG_ACPI_PROCFS_POWER=n by default.
> If you still want to use that I/F, now you need to set
> CONFIG_ACPI_PROCFS_POWER=y.
> 
> Please re-open if that doesn't work.
> 
> We will add a run time warning that this code
> is scheduled to be deleted entirely.  yes, we try
> to maintain compatibility with the installed user-space,
> but there are limits to how old a user-space that
> it makes sense for the upstream kernel to support.

Len,

The configuration for kernels <= 2.6.36.2 has always had CONFIG_ACPI_PROCFS_POWER=y

With kernels < 2.6.36 the I/F works. 
With kernel >= 2.6.36 the I/F does not work.

Please re-open this bug.

Alan.
Comment 10 Zhang Rui 2010-12-16 00:49:52 UTC
please use acpi_listen to see if there is ACPI battery events in 2.6.36 kernel.
Comment 11 Alan Bartlett 2010-12-16 04:30:18 UTC
(In reply to comment #10)
> please use acpi_listen to see if there is ACPI battery events in 2.6.36 kernel.

Using kernel-2.6.36-2.el5.elrepo (i.e. linux-2.6.36.2) for the experiment.

Booted up with the external power supply connected.
Invoked acpi_listen.
Unplugged the external power supply and the following ten lines were output:

ac_adapter AC 00000080 00000000
battery BAT0 00000080 00000001
processor CPU0 00000080 00000003
processor CPU1 00000080 00000003
processor CPU0 00000080 00000002
processor CPU1 00000080 00000002
processor CPU0 00000080 00000001
processor CPU1 00000080 00000001
processor CPU0 00000080 00000000
processor CPU1 00000080 00000000

After waiting for about 30 seconds, plugged the external power supply back in and the following three lines were output:

ac_adapter AC 00000080 00000001
battery BAT0 00000080 00000001
battery BAT0 00000080 00000001

Is that an appropriate test? Is the output significant?
Comment 12 Alan Bartlett 2010-12-20 23:23:29 UTC
Any further tests that I can carry out?
Comment 13 Alan Bartlett 2011-01-08 19:10:05 UTC
Created attachment 42882 [details]
Repeated test result using linux-2.6.37

Now that linux-2.6.37 is the current stable version, this attachment contains the output of an identical set of commands to that provided in attachment 40232 [details].
Comment 14 Florian Mickler 2011-03-29 21:29:46 UTC
Is this still a problem in 2.6.38.y?
Comment 15 Alan Bartlett 2011-03-29 23:50:39 UTC
(In reply to comment #14)
> Is this still a problem in 2.6.38.y?

Florian, I haven't checked (as it seemed that all 'upstream' interest had been lost back in December 2010) but, as you've now asked, I'll test in the coming hours and report back with my findings.
Comment 16 Alan Bartlett 2011-03-30 15:12:25 UTC
Created attachment 52642 [details]
Repeated test results, using linux-2.6.38.2

Florian, 

Yes this issue still occurs with 2.6.38.y series kernels.
Comment 17 Florian Mickler 2011-03-30 19:27:36 UTC
Thanks for the update!

Zhang, do you have any guess at where the problem could be?
Comment 18 Zhang Rui 2012-01-18 02:26:17 UTC
Sorry I lost track of this bug.

Anyway, it's great that kernel bugzilla is back.

Alan,
can you please verify if the problem still exists in the latest upstream
kernel?
Comment 19 Alan Bartlett 2012-01-23 17:37:43 UTC
Created attachment 72178 [details]
Repeated test results, using linux-3.2.1
Comment 20 Alan Bartlett 2012-01-23 17:48:04 UTC
Sorry for the delay. I had to set up the relevant laptop with a CentOS 5 system, build the ELRepo kernel-ml-3.2.1-0.el5.elrepo package, install and boot it.

In the attachment (id=72178), all the tests performed should be obvious. When performing the "acpi_listen", it was first invoked with the external mains PSU connected and then the "plug was pulled". After waiting to ensure there was no more output forthcoming, the process was CTRL-C'd. Acpi_listen was then re-invoked and then the plug was re-insterted.

One final comment. Logging in to a Gnome desktop as an ordinary user, there is a power icon present. Whether the system is running from the external mains PSU or the battery the same icon is displayed -- the "mains power lead". It seems that user-land is unable to distinguish between the two power states.
Comment 21 Lan Tianyu 2013-04-09 05:54:29 UTC
Hi:
    From your test result in #Comment #19, I see the notify event and battery/AC status are correct.

ac_adapter AC 00000080 00000000  <=== AC event and status 0(not present)
battery BAT0 00000080 00000001
processor CPU0 00000080 00000003
processor CPU1 00000080 00000003
processor CPU0 00000080 00000002
processor CPU1 00000080 00000002
processor CPU0 00000080 00000001
processor CPU1 00000080 00000001
processor CPU0 00000080 00000000
processor CPU1 00000080 00000000
^C

[root@Duo1 bz23812]# acpi_listen
ac_adapter AC 00000080 00000001  <=== AC event and status 1(present)
battery BAT0 00000080 00000001

For Gnome icon, have no idea how the Gnome deal with it and now at last, acpi event and reported status are correct. So close this bug.

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