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.
is there a newer version of HAL that talks to /sys/class/power_supply?
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.
Dag, Do I understand that you have since moved to RHEL 6, and so this is (personally) no longer a problem for you?
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 :-)
/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.
[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.
> /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/*/*"
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).
(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.
please use acpi_listen to see if there is ACPI battery events in 2.6.36 kernel.
(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?
Any further tests that I can carry out?
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].
Is this still a problem in 2.6.38.y?
(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.
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.
Thanks for the update! Zhang, do you have any guess at where the problem could be?
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?
Created attachment 72178 [details] Repeated test results, using linux-3.2.1
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.
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.