01_proc_sys_batteries.patch causes a regression making gnome-power-manager not detect the battery properly

Binary package hint: gnome-power-manager

Using hardy current. This problem has just recently emerged with the latest updates on a
Clevo M720R on intel hardware, C2D 2,4 GHz

The gnome-power-manager is confused about battery state.
If I set the icon to always be shown in the gnome-power-manager, its status isn't updated when I pull the AC-plug.
Thus, I never get an accurate reading of the battery level.

I don't know if it's relevant to the bug but I've used to have a regression where gpm detected two batteries (but only one physical existed).
Know, only one battery is detected. Could it be that the "wrong" battery has been eliminated?

Turns out the 01_proc_sys_batteries.patch causes this regression.
If I revert this patch. Two batteries show up on gnome-power-manager and proper battery behaviour is restored.

Thank you for your bug report. However, it's not complete. We'd like to get some more information before the developer can fix the bug.
First of all the output of the command 'gnome-power-bugreport.sh' added in a file would help. Also we'd like to have the output of the command 'hal-find-by-capability --capability "battery" ', which lists all batteries available on the system(please do this with and without the patch).
The output of 'dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'" ' is also nice to have, but this command doesn't list things like the previous, but it's more like syslogd. Everytime something happens(power (un)plugged, battery almost empty, etc), it will be listened here(the command has to be executed before the event).
Would you also include the output of this command: 'gconftool --recursive-list /apps/gnome-power-manager'

Thank you for your time,
Sense Hofstede

I see this bug too, on a dell latitude d820, If i can provide any helpful info that hasn't been provided above please let me know.

Thank you for your help. Since there is a duplicate describing the same problem and someone else confirming it this bug is confirmed.
A note for the developers: in the duplicate, bug #194960, are also log files posted if you need more information.

I'm also having this problem, but with KDE 3.5. The battery icon can tell when the system has been unplugged, and seems like it updates itself then, but otherwise sits there on the same percentage number regardless of the actual charge in the battery. For example, it spent hours yesterday at 5% charge despite the "fully charged" light on the front of my machine being on. When I unplugged the machine to sit on my bed with it, when the backlight dimmed, the icon updated itself.

Interestingly enough, prior to this, for a while the machine listed itself as having two batteries for some reason, Battery #1 would be accurate and updated, and Battery #2 would be this non-updated thing. Even though they're the same battery.

I'd attach some files, but most of the commands seem to be Gnome-specific, and I'd rather just run/post all of them at once. Any help I can provide shall be provided.

Hi, I'm suffering from the same problem. NB asus V1S.
surprisingly enough running $acpi -b shows the state of the battery correctly.

Hi,

  I'm also on Hardy and have all the updates installed. An update that i did
  a couple of days back triggered this issue. Unless there's a change in the
  state of the battery (either plug in AC power/remove AC), there's no change
  in the battery state that is displayed in the batter applet in the system tray.

  For e.g.: I had my laptop running on battery and then plugged in to AC power.
  At that time 57% of the battery had been discharged and that is the state
  that is shown on the batter applet till now.

  The attached screenshot shows the battery applet. However 'acpi' output is
  different (and probably correct)

  $ acpi -b
        Battery 1: charging, 98%, 48:00:00 until charged

-Vikas

Since it also affects KDE I think the bug lies deeper in power-manager.

I chased this last night; it's a bug in hal. https://bugs.freedesktop.org/show_bug.cgi?id=13669#c7 implies it's moot, but this bug is evidence that it remains amiss.

Moving my comments / findings from my other bug #196151 report here. Attached is an archive containing output form the commands that Sense listed above. For the dbus-monitor command I plugged and unplugged power several times and let the machine sit for a couple minutes to let the battery drain a bit to create some events. Also note that as of installing a few updates this morning the GPM icon does not seem to be reliably changing to reflect whether or not AC is plugged in. It seems that the first couple times the power state changes after boot, it always shows the battery alone, with no AC plug. After plugging/unplugging a few times, the icon changes appropriately again. All of the previous behavior I reported in #196151 remains, however.

Thought I'd point out that this bug is very closely related to bug 194052.

Thank you. It looks like this bug report and the one you gave are both about the wrong battery being selected.
Another question to the people who have the problem: is the remaining battery time absurd? Someone reported that in bug #196501 and I think it could have a similar cause.

In my case, it reports that the remianing battery time is unknown. I've
discovered that GPM also seems to have a memory leak, not sure if it's
related to this or not though. see #196688

On Thu, Feb 28, 2008 at 2:01 PM, Sense Hofstede <email address hidden> wrote:

> Thank you. It looks like this bug report and the one you gave are both
> about the wrong battery being selected.
> Another question to the people who have the problem: is the remaining
> battery time absurd? Someone reported that in bug #196501 and I think it
> could have a similar cause.
>
> --
> 01_proc_sys_batteries.patch causes a regression making gnome-power-manager
> not detecting the battery properly
> https://bugs.launchpad.net/bugs/194719
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
-Regards-

-Quentin Hartman-

Hi,

For me the battery charge as shown never diminishes. I can work for
hours and the charge shown will be the actual charge in the battery when
the ac was removed. Meanwhile I can see the actual charge decreasing
via /proc.

If I plug the ac back in then the correct remaining battery charge is
reported. I think that the charge as shown is only updated on power
change events.

Chris

On Thu, 2008-02-28 at 19:01 +0000, Sense Hofstede wrote:
> Thank you. It looks like this bug report and the one you gave are both about the wrong battery being selected.
> Another question to the people who have the problem: is the remaining battery time absurd? Someone reported that in bug #196501 and I think it could have a similar cause.
>

That's exact behavior I'm seeing.

On Thu, Feb 28, 2008 at 2:36 PM, Chris McCauley <email address hidden>
wrote:

> Hi,
>
> For me the battery charge as shown never diminishes. I can work for
> hours and the charge shown will be the actual charge in the battery when
> the ac was removed. Meanwhile I can see the actual charge decreasing
> via /proc.
>
> If I plug the ac back in then the correct remaining battery charge is
> reported. I think that the charge as shown is only updated on power
> change events.
>
> Chris
>
>
> On Thu, 2008-02-28 at 19:01 +0000, Sense Hofstede wrote:
> > Thank you. It looks like this bug report and the one you gave are both
> about the wrong battery being selected.
> > Another question to the people who have the problem: is the remaining
> battery time absurd? Someone reported that in bug #196501 and I think it
> could have a similar cause.
> >
>
> --
> 01_proc_sys_batteries.patch causes a regression making gnome-power-manager
> not detecting the battery properly
> https://bugs.launchpad.net/bugs/194719
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
-Regards-

-Quentin Hartman-

>Another question to the people who have the problem: is the remaining battery time absurd?
For me it's not quite absurd, but definitely wrong...

"51:18h to charge"

I'd say so, considering it's fully charged according to the light on the front...

Here, it only shows "Ladezeit unbekannt" (Charging time is inknown).

After briefly discussing this bug with Seb and Brian yesterday, it is worth noting that we should consider one of these options, too:

1) Drop this patch (01_proc_sys_batteries);
2) Invert the logic in this patch so that Gutsy's behaviour (reading /proc/acpi) is restored. This means ignoring sysfs for power in instances where both /proc/acpi and sysfs exist.

From what I gather, the sysfs interface is preferable to /proc/acpi, but Seb mentioned there also being backlight issues even with the slew of patches backported from fd.o hal.git.

Choosing option (1) above is fairly straightforward: it eliminates this and several other bugs at the expense of possibly duplicated power source entries in g-p-m (this latter bit possibly being as major as "omgconfusedbbq" - a minor annoyance but bearable IMO). Gutsy's behaviour will be restored mostly (save the duplication).

Choosing option (2) above is less straightforward: it also eliminates this and several other bugs; Gutsy's behaviour will be restored. However, Ubuntu will need to maintain this "inverted patch" for several years, since upstream has already deprecated reading /proc/acpi for power in favour of sysfs. Ultimately the questions involved must include, "Will the power estimation and backlight regressions be fixed in time for Hardy?"

In light of 8.04 being LTS, we should entertain keeping the path that seems to cause fewer regressions.

Thoughts?

Hi,

It sounds like the simplest course in terms of maintenance is option 1.
The original battery duplication will get fixed upstream.

Chris

On Fri, 2008-02-29 at 13:58 +0000, Daniel T Chen wrote:
> After briefly discussing this bug with Seb and Brian yesterday, it is
> worth noting that we should consider one of these options, too:
>
> 1) Drop this patch (01_proc_sys_batteries);
> 2) Invert the logic in this patch so that Gutsy's behaviour (reading /proc/acpi) is restored. This means ignoring sysfs for power in instances where both /proc/acpi and sysfs exist.
>
> >From what I gather, the sysfs interface is preferable to /proc/acpi, but
> Seb mentioned there also being backlight issues even with the slew of
> patches backported from fd.o hal.git.
>
> Choosing option (1) above is fairly straightforward: it eliminates this
> and several other bugs at the expense of possibly duplicated power
> source entries in g-p-m (this latter bit possibly being as major as
> "omgconfusedbbq" - a minor annoyance but bearable IMO). Gutsy's
> behaviour will be restored mostly (save the duplication).
>
> Choosing option (2) above is less straightforward: it also eliminates
> this and several other bugs; Gutsy's behaviour will be restored.
> However, Ubuntu will need to maintain this "inverted patch" for several
> years, since upstream has already deprecated reading /proc/acpi for
> power in favour of sysfs. Ultimately the questions involved must
> include, "Will the power estimation and backlight regressions be fixed
> in time for Hardy?"
>
> In light of 8.04 being LTS, we should entertain keeping the path that
> seems to cause fewer regressions.
>
> Thoughts?
>

For me, at least, the old behavior (i.e. gpm reporting twice the amount of actual batteries), also caused other issues, such as absurd notes on remaining power, suspend and other things being triggered when they shouldn't (and not triggered when they should), and so on.

I think we should try to fix this with patches from git, didn't someone mention here or on another related bug report that hal-git actually worked fine? I have been using the following two patches

http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=7430beeb6c6fd6c8e51c24df20fd53c526aed6e8
http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=f018f6480384e2607aa3cac6aad5f114b832ebc0

against the latest hardy hal package and most of my problems seem to be gone.

Right now, I only seem to have problems that I've always had (gpm saying I'm on battery power, when battery becomes fully charged, gpm saying suspend failed, when in fact it didn't, and so on).

I say, try with at least these patches before reverting 01_proc_sys_batteries.

Regards,
K.

Is this bug caused by the battery detection in the kernel or in hal?

In HAL. HAL fails to reread battery status from sysfs.

I'd say that someone should write a temporally patch for hardy, and that we're going to use sysfs in 8.10. When it's October I hope the errors with sysfs will be fixed and I think that's enough time for that to happen. If it doesn't happen fast enough we could always put a few Ubuntu developers on the issue and send the patch upstream.

But I'm not very experienced with programming and Ubuntu, so there is a large change I just said some non-sense. ;)

On Fri, Feb 29, 2008 at 8:58 AM, Daniel T Chen <email address hidden> wrote:

> Thoughts?
>

Well, from my relatively ignorant point of view, it seems that it would be
worthwhile to attempt to get this actually fixed in time Hardy. We really
don't want people living with this sort of oddness for 3 years. That being
it said, it would also be wise to have an acceptable fallback (reverting the
patch?) should that prove impossible. I'll commit to devoting what resources
I have to getting this done right in time for Hardy. That will primarily
amount to being a guinea pig though, since I have zero experience hacking on
things this low-level. At this point it seems speed is important, and I
think that would be the best way I could help.

--
-Regards-

-Quentin Hartman-

In bug #197090 someone reported a similar issue but solved it by restarting hal. Does that work for you?

On Sat, Mar 1, 2008 at 6:35 AM, Sense Hofstede <email address hidden> wrote:

> In bug #197090 someone reported a similar issue but solved it by
> restarting hal. Does that work for you?
>

No, restarting hal does not work in my case.

--
-Regards-

-Quentin Hartman-

I've posted test packages at http://www.trilug.org/~crimsun/hal/. Please leave feedback here.

I'm wondering if HAL is completely to blame for this behavior. Take this with a grain of salt because I don''t know exactly where HAL sits in the stack of things, but I've noticed today that the output of 'cat /proc/acpi/battery/BAT1/*' shows that the 'remaining capacity' line is no longer reporting correctly as I thought it had been previously. Is this a HAL deficiency? I thought the /proc tree didn't have much, if anything to do with HAL.

I've been noticing some inconsistency in behavior on this bug, including an apparent memory leak I mentioned in #196688. It seems the sequence of events is:

1- Boot up laptop.
2- GPM does not report drain correctly, including displaying on the battery icon even when on AC. At this point "/proc/acpi/battery/BAT1/*" "remaining capacity" is also stuck at the level the machine was presumably at when it booted.
3- Changing power state (plugging in and removing AC) a few times seems to kick it into a more correct state, with the GPM icon correctly toggling between AC and BAT, though still not showing changes in charge level. "Remaining Capacity" in /proc/... is now updating.
4- Usually at this point GPM runs away and consumes all available RAM and swap until it is killed, as I describe in #196688.

This seems to be getting to be a fairly complex problem. Any thoughts? I'll be trying Daniel's packages and see what they do.

yoops, I just realized those packages are i386, and I'm running 64-bit here. How would I go about re-creating them on my side? I'm fairly familiar with compiling software, but patching and packaging is a little shaky.

Please try the updated ~2 debs (posted at the same URL).

Your debs fix at least part of the problem.
It now correctly shows the status of the battery ( plugged in or discharging ), and updates the %, but also still says "Battery discharge time is unknown", while acpi -b says "Battery 1: discharging, 65%, 02:37:38 remaining"

I'm using the ~3 debs and they seem to work just fine for me so far.

@Bart: That's because gnome-power-manager has not finished profiling your batteries yet, after a few charges/discharges it will report that more accurately than acpi -b.

Bug in hal, not in gnome-power-manager

Merged Daniel's branch, will upload today.

This bug was fixed in the package hal - 0.5.10-5ubuntu8

---------------
hal (0.5.10-5ubuntu8) hardy; urgency=low

  [ Scott James Remnant ]
  * Add debian/patches/96_uinput_device_support.patch: This creates a HAL
    device for the uinput device, allowing us to set ACLs for it using
    PolicyKit/ConsoleKit.

  [ Daniel T Chen ]
  * Add debian/patches/97_fix_power_info_via_sysfs.patch: Fix battery status
    reading from /sys. Patches taken from upstream GIT head.
    (LP: #194052, #194719)

  [ Martin Pitt ]
  * Add debian/patches/02_sysfs_battery_serial.patch: Get battery serial
    number from sysfs. Patch taken fro upstream GIT head.

 -- Martin Pitt <email address hidden> Mon, 03 Mar 2008 15:02:40 +0100

With the installation of hal 0.5.10-5ubuntu8 tonight, this problem seems to be solved for me.

For me, the new hal didn't fix the problem. Right now, both g-p-m and acpi show that my battery is present but it is not. This is not a problem of a slow update of the battery state because the state is wrong since I switched on my computer.

Maybe this is to be discussed on another bug report? Some of the duplicates may not be duplicates.

I am using an up to date Hardy on a Lenovo 3000 N200.

My bug report (https://bugs.launchpad.net/bugs/194201) was marked duplicate of this, But this patch/update doesn't fix my battery issue.

Daniel

Add one more problem to battery detection issue:

Last night the plug got pulled on the laptop and it drained the battery, however, it did not even attempt a shutdown as it was supposed to do when battery levels went to critical.

Ubuntu Hardy - fully up-to-date
Dell XPS M1530

A new version is going to be uploaded soon. Until then it's placed here: https://edge.launchpad.net/~pitti/+archive
Please test it to see if it solves the problem for you.

It seems fixed for me with your packages : I tried plugging and unplugging, putting and removing the battery, the state reported is correct and the remaining capacity percentage seems correctly updated.

I'm going to do more extensive testing but thank you anyway!

Don't say thanks to me, Mark Pitt has done the hard work. ;) Great it works now. There is a possibility that some small changes are going to be made to the package, so if the version appears in the official repositories, could you also tell if that one works? Thanks.

A comment: bug #135548 and bug #154003 look very similar. Do you think they've got the same cause?

Same here, 0.5.10+git20080301-1ubuntu1~ppa3 fix my battery problem. :D

Misterious, screen brightness is lower now, but i'm not sure if it is releated.

Thanks! :)

Bad news : with the new hal my external USB drive fails to be mounted automatically. The error message is in French but it means "bad mounting options". I can see no error in either 'dmesg' or /var/log/daemon.log .

Maybe there is another reason but I'm sure it worked before hal upgrade and it don't work know. Is anybody experiencing the same issue?

PS The battery status is still fine though :-)

Hi,

Jim Braux-Zin [2008-03-04 17:36 -0000]:
> Bad news : with the new hal my external USB drive fails to be mounted
> automatically. The error message is in French but it means "bad mounting
> options". I can see no error in either 'dmesg' or /var/log/daemon.log .

I think it stumbles over the 'usefree' mount option. Please upgrade to
gnome-mount 0.7-2ubuntu2 (in Hardy since yesterday) and check whether
it works again?

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

My 5 today: #193521 (jockey), #151025 (gnome-mount), #195548 (jockey),
#194963 (jockey), #194052 (gnome-power-manager, hal)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day

Yep it works! I had to wait for the new packages to propagate through the French servers.

The HAL updates seem to have fixed it for me.

Clean install of Hardy and it is not working!

$ acpi -v
acpi 0.09

Copyright (C) 2001 Grahame Bowland.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
osteenbergen@nuxWeb:~$ acpi -V
     Battery 1: charging, 100%, until charged
     Thermal 1: ok, 40.0 degrees C
  AC Adapter 1: off-line

No power, but charging...

Hi,

osteenbergen [2008-03-11 19:45 -0000]:
> Clean install of Hardy and it is not working!

Can you please check "dpkg -s hal|grep Version" and confirm that you
actually use 0.5.10+git20080301-1ubuntu1?

~$ dpkg -s hal|grep Version
Version: 0.5.10+git20080301-1ubuntu1

osteenbergen,

oh, you are saying that the output of "acpi -V" is wrong? How about gnome-power-manager (the battery icon in the desktop panel tray), does that work correctly? If so, can you please file a new bug against 'acpi'? Thank you!

That also doesn't work. It reports the same information 100% and charging without ac attached.
Tried reinstalling but no luck.

Same on my laptop :

$ dpkg -s hal|grep Version
Version: 0.5.11~rc2-1ubuntu6

Charging but no AC attached is reported

osteenbergen: ah, so the "acpi -v" output is indeed wrong? Can you please report a new bug about this (against 'linux'), since this bug has a lot of subscribers, and the precise issue here is fixed already? Thank you!

Here is the output of "hal-device `hal-find-by-capability --capability battery`" after restarting hal "sudo /etc/init.d/hal restart".

rick@rick-laptop:/etc/init.d$ hal-device `hal-find-by-capability --capability battery`
udi = '/org/freedesktop/Hal/devices/acpi_C171'
  battery.serial = '16425' (string)
  info.capabilities = { 'battery' } (string list)
  battery.charge_level.warning = 2721 (0xaa1) (int)
  info.category = 'battery' (string)
  info.product = 'Battery Bay' (string)
  battery.technology = 'lithium-ion' (string)
  battery.reporting.warning = 189 (0xbd) (int)
  battery.rechargeable.is_discharging = false (bool)
  battery.model = 'Primary' (string)
  battery.charge_level.granularity_1 = 1440 (0x5a0) (int)
  battery.charge_level.granularity_2 = 1440 (0x5a0) (int)
  linux.acpi_path = '/proc/acpi/battery/C171' (string)
  battery.charge_level.design = 54201 (0xd3b9) (int)
  battery.charge_level.low = 547 (0x223) (int)
  battery.reporting.last_full = 3764 (0xeb4) (int)
  battery.reporting.technology = 'LIon' (string)
  battery.charge_level.current = 54201 (0xd3b9) (int)
  battery.reporting.granularity_1 = 100 (0x64) (int)
  battery.is_rechargeable = true (bool)
  battery.reporting.current = 3764 (0xeb4) (int)
  battery.reporting.granularity_2 = 100 (0x64) (int)
  battery.voltage.unit = 'mV' (string)
  battery.charge_level.capacity_state = 'ok' (string)
  info.parent = '/org/freedesktop/Hal/devices/computer' (string)
  battery.rechargeable.is_charging = false (bool)
  battery.reporting.rate = 0 (0x0) (int)
  battery.charge_level.rate = 0 (0x0) (int)
  battery.reporting.design = 3764 (0xeb4) (int)
  battery.present = true (bool)
  info.udi = '/org/freedesktop/Hal/devices/acpi_C171' (string)
  linux.acpi_type = 0 (0x0) (int)
  battery.voltage.design = 14400 (0x3840) (int)
  battery.reporting.low = 38 (0x26) (int)
  battery.type = 'primary' (string)
  battery.reporting.unit = 'mAh' (string)
  battery.voltage.current = 16713 (0x4149) (int)
  battery.charge_level.last_full = 54201 (0xd3b9) (int)
  battery.charge_level.percentage = 100 (0x64) (int)
  battery.vendor = 'Hewlett-Packard' (string)
  linux.hotplug_type = 4 (0x4) (int)
  battery.charge_level.unit = 'mWh' (string)

Disregard my previous comment. It was meant for bug 220324.

Rick

I am having exactly this issue: gnome-power-manager does not update power-consumption (shows approx. 6W constantly, was 18W on Feisty), remaining battery time constantly 3h (should be 1:30h - old battery).
Plugging / unplugging power is detected.

$ dpkg -s hal|grep Version
Version: 0.5.11~rc2-1ubuntu8.1

Was the bug reintroduced in subsequent updates? I am not aware of having noticed this issue some weeks ago.
I'm also checking https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/194960.