FS#9572 - hal reports batteries duplicate + sysfs battery doesn't update

Attached to Project: Arch Linux
Opened by Loic Nageleisen (lloeki) - Thursday, 14 February 2008, 09:36 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 14 May 2009, 05:23 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan de Groot (JGC)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 13
Private No

Details

Description:
since we have both /proc/acpi and /sys enabled in the kernel for battery information, hal mistakenly thinks there's two.
also, hal sysfs code does not poll every 30s like for proc.

so if we use only sys, we break not sys-aware software like xfce panel applet. besides, as it is not polled by hal, the sys information is not reliable.

also, whether we use only sys or both sys and proc, the sys information will have side effects on hal-aware application behaviors, even with proc enabled: the information will be the same as when hal was started, thus on a discharging scenario it will report a non-existent potential charge when in fact we're hitting the red zone (as correctly notified by proc) of the very same battery, thus we may hit power shortage issues because of wrong information (that is there's a backup battery with power left available, so supposedly no need to shutdown)

therefore I suggest to disable ACPI_SYSFS_POWER for now (it's at best unreliable anyway) and leave only ACPI_PROCFS_POWER, at least until we have the updated hal in extra.

Additional info:
fixed upstream in git. see http://dkukawka.blogspot.com/2008/01/hal-sysfs-acpi-batteries-fixed.html

This task depends upon

Closed by  Tobias Powalowski (tpowa)
Thursday, 14 May 2009, 05:23 GMT
Reason for closing:  Fixed
Comment by héctor (hacosta) - Friday, 22 February 2008, 01:46 GMT Comment by João Rodrigues (gothicknight) - Monday, 03 March 2008, 09:49 GMT
I can confirm this behavior.
Comment by Victor Román (TecnoVM64) - Wednesday, 12 March 2008, 00:41 GMT
Same here, it's an annoying issue :(
Comment by Matt Taylor (dingus) - Wednesday, 12 March 2008, 00:45 GMT
Apparently this should be fixed in the next hal, which should be out by monday. (This is the information I glean from the mailing list anyway)
Comment by Loic Nageleisen (lloeki) - Wednesday, 12 March 2008, 08:30 GMT
if any of you is really annoyed, do what I did:

$ cp -R /var/abs/extra/system/hal ./
$ cd hal
$ git clone git://git.freedesktop.org/git/hal
$ mv hal hal-0.5.10
$ tar cfz hal-0.5.10.tar.gz hal-0.5.10
$ sed -i "s/md5sums=('.*'/md5sums=('$(md5sum hal-0.5.11.tar.gz | cut -d ' ' -f1)'/" PKGBUILD
$ makepkg
# pacman -U hal-0.5.10-1-i686.pkg.tar.gz
# /etc/rc.d/hal restart
Comment by Martin Peres (MuPuF) - Thursday, 03 April 2008, 06:30 GMT
I can confirm the bug too, very nice bug report !
Comment by Ludovic Teixeira Silvestre (hellknight) - Friday, 29 August 2008, 06:35 GMT
I still have the same problem with the hal 0.5.11-1. Hal recognize 2 batteries and sysfs battery information doesn't update.
Comment by Jan de Groot (JGC) - Friday, 29 August 2008, 06:44 GMT
Can't reproduce here, only issue I have is that the sysfs battery is a bit delayed in updates. After plugging in the power it takes a few seconds before gnome-power-manager shows up.
Comment by Sébastien Mazy (melyadon) - Friday, 29 August 2008, 07:07 GMT
I had the same issue (2 or 3 batteries showing up in gnome-power-manager) and it's gone with some update (unfortunately I don't remember which).
Comment by Ludovic Teixeira Silvestre (hellknight) - Sunday, 31 August 2008, 21:18 GMT
I found someone else with the same problem on the FreeDesktop Bugzilla (https://bugs.freedesktop.org/show_bug.cgi?id=16798) and he has a laptop similar to mine, which is a Acer TravelMate 4000 Serie, while his is a 4100 Serie. The similarity, concerning the batteries, between those 2 models is that both have a Smart Battery System. Really don't know if it has anything to with the problem, but it's strange that everyone else, but us, doesn't have this problem anymore.

If more information is needed, just say something that I'll send it right away.
   lshal.txt (121.8 KiB)
Comment by Ludovic Teixeira Silvestre (hellknight) - Friday, 05 September 2008, 11:41 GMT
Problem partialy solved since upgrade to kernel 2.6.26.3.
Now sysfs battery information updates (every seconds or two), although it seems its information might be incorrect, because my laptop shuts down when I have 15% of battery charge.
There's still two batteries showing up, don't know if it's because we use both /proc and /sys or if it's a kernel bug, because both /proc and /sys shows two batteries while they should be showing only one (I think...).
I'll check the kernel changelog from 2.6.26.2 to 2.6.26.3 to find what happened.

Comment by Jan de Groot (JGC) - Sunday, 12 October 2008, 12:51 GMT
Is this fixed with kernel 2.6.27?
Comment by Ludovic Teixeira Silvestre (hellknight) - Sunday, 12 October 2008, 22:39 GMT
Still not fixed with kernel 2.6.27.
HAL still shows 2 batteries (even if none is connected), my laptop shuts down (hard shutdown, not the normal process) when HAL shows there's still 15-17% of battery charge, but when I power on the laptop right after, it shows 0% of charge.
HAL doesn't seems to recognize when I pull off the battery, although he knows when I plug it in.

The first affirmation is based on information from g-p-m, conky, /proc and /sys, and the second from g-p-m only. I'll try to see if lshal does send/receive an event when I plug in/out my battery.
I'm afraid that the first problem (2 batteries and charge incorrect) are because of the kernel or from my battery, because both /proc and /sys should show the correct information.
Comment by Glenn Matthys (RedShift) - Friday, 05 December 2008, 21:05 GMT
What's the status of this issue? Have you guys tried with a custom DSDT for your laptops?
Comment by Ludovic Teixeira Silvestre (hellknight) - Saturday, 06 December 2008, 21:54 GMT
I still have the issue and no, haven't tried a custom DSDT, because I don't have time to edit mine.
For now I can live with this issue, but in a month or so, I'll work on it, because I really don't have any free time for now.
Although, I appreciate if someone could tell me how to catch acpi events, or which log file normally contains this events. Also need to know where to look for my battery charge, besides conky and HAL.
Comment by Ludovic Teixeira Silvestre (hellknight) - Tuesday, 30 December 2008, 16:42 GMT
Since I uninstaled acpid, battery status doesn't update anymore.

Neither conky or g-p-m have correct battery information.
If I read the battery charge through SYSFS (/sys/class/power_supply/BAT0/charge_now), the charge is incorrect (doesn't get updated), so every HAL-dependent application have incorrect information.
If I read the battery charge through PROCFS (/proc/acpi/battery/BAT0/state), the charge is correct and application using PROCFS (like conky) gets updated, but doesn't get automatically updated unless I read the file again. The battery status in SYSFS also gets updated, so every HAL-dependent application have the information updated.

I think it kind of worked before because I was running the acpi daemon, which was getting all information from PROCFS and probably was updating SYSFS. But this daemon shouldn't be necessary, SYSFS should update every 30s the battery status, and HAL would then get the events from D-Bus every 30s and update every application depending on him.

I forgot to say that I don't have the following modules loaded: ac, battery, bay, container, acer-wmi. I explicitly blacklisted them in rc.conf because only the sbs module is required so my battery and ac-adapter can work.
Comment by Tobias Powalowski (tpowa) - Tuesday, 06 January 2009, 08:29 GMT
Status on .28 kernel?
Comment by ndlarsen (ndlarsen) - Monday, 19 January 2009, 11:23 GMT
Well, it seems that I might still have this issue on kernel26 2.6.28-3 as well as on kernel26 2.6.28.1-1 from testing. Neither SYSFS nor PROCFS updates regularly, only on AC event such as plugging in and out.
Comment by Ludovic Teixeira Silvestre (hellknight) - Monday, 19 January 2009, 12:39 GMT
No, still not working with kernel 2.6.28 (core repo, not testing).

I've been searching a lot about how HAL works with ACPI and found the following: HAL doesn't need acpid to be running, it can listen to /proc/acpi/event by himself, but if acpid is running, it will listen to /var/run/acpid.socket. The problem is, with or without acpid, all events get caught but the battery charge. I believe it must be acpid or HAL to be polling the battery to know those values, but it's not happening.
The only way to get updated battery charge is to cat /proc/acpi/battery/BAT0/state or create an ACPI event like plugging the AC Adapter, then the info in sysfs gets updated, conky gets updated and HAL gets updated. By the way, HAL polling does work, but because it's listening to sysfs, it doesn't get any new value, that's why when running lshal -m I don't see the polling "happening".
Comment by ndlarsen (ndlarsen) - Tuesday, 27 January 2009, 14:23 GMT
Running kernel26 2.6.28.2-1 and still have this issue.
Well, hal may not be needing acpid but it's automatically being started by hal on my system. /proc/acpi/battery/BAT0/state doesn't get updated here so cat'ing it is a no go here.
Honestly. I'm getting slightly confused by now. Is this issue related to hal, acpid or the kernel?
Any suggestion on what to do?

Added url to a topic I made as I think it's related. http://bbs.archlinux.org/viewtopic.php?id=63305

Cheers.
Comment by Tobias Powalowski (tpowa) - Sunday, 10 May 2009, 06:20 GMT
any update on .29 kernel series?

Loading...