Bug 499948

Summary: Gnome-Power-Manager battery level sticks at 100%, causing unpredictable shutdowns
Product: [Fedora] Fedora Reporter: J Gallagher <jbgallagher2000>
Component: gnome-power-managerAssignee: Richard Hughes <richard>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 13CC: abarto, achowdhurig, alwin.laureijs, amturnip, bbaetz, clancy.kieran+redhat, dennisfen, dominik, hackob, hristozov, jsaucier, marcbuigues, matzilla, maurizio.antillon, mishu, moondrake, mp, orlandoarias, palazzotti, rhughes, richard, sanjay.ankur, sb, seawolf89, s.so, vic, waf, zytemp2g
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-27 10:11:44 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
screenshot of battery icon and statistics
none
screenshot of battery icon and AC statistics
none
Daemon verbose log file (annotations start with '<---')
none
Monitor log file (annotations start with '<---') none

Description J Gallagher 2009-05-09 08:22:08 EDT
Description of problem:
In Fedora 11 Preview, on batter power on an Acer Aspire One, the battery level constantly reads 100% rather than gradually reducing. This causes the system to suddenly and unpredictably power off when the battery is drained, possibly at dangerously low levels (which could damage the battery)


Version-Release number of selected component (if applicable):
gnome-power-manager-2.6.1-3.fc11.i586
kernel-2.6.29.2-126.fc11.i686.PAE

How reproducible:

Everytime I unplug AC power on the laptop.

Steps to Reproduce:
1. Unplug the ac power
2. monitor the battery level in g-p-m icon
3.
  
Actual results:
Battery level remains at 100% as the physical battery drains, resulting in sudden unpredictable shutdowns.

Expected results:
Battery level should gradually reduce to near 0% and display warnings when battery is nearly drained.

Additional info:
Acer Aspire One, Battery

Vendor: SIMPLO
S/N: IC8C
Model: UM08A72
Current Charge: 23.9 Wh
Last Full Charge: 23.9 Wh
Comment 1 J Gallagher 2009-05-12 04:58:36 EDT
I gave this bug priority 'URGENT' in the hope that it would be looked at urgently, it seems a dangerous bug to me, potentially causing battery damage. I have confirmed the same error with the battery in a Dell Inspiron 1520

After 20 minutes of battery discharging I have:

Percentage charge: 100.0%
Vendor: Samsung SDI
Technology: Lithium Ion
Serial number: 26104
Model: DELL GK4798
Capacity: 93.4% (Good)
Current charge: 57.7 Wh
Last full charge: 57.7 Wh
Charge rate: 0.7W
Comment 2 Richard Hughes 2009-05-12 05:25:26 EDT
What does "devkit-power --dump" say when the battery is charging, is fully charged and also discharging? Thanks.
Comment 3 J Gallagher 2009-05-12 06:53:36 EDT
While battery is discharging (this is after about 1 hour, still showing 100%) I have:

$ devkit-power --dump
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC
  vendor:               
  model:                
  serial:               
  power supply:         yes
  updated:              Tue May 12 09:36:23 2009 (8158 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             no

Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Samsung SDI
  model:                DELL GK4798
  serial:               26104
  power supply:         yes
  updated:              Tue May 12 09:36:24 2009 (8157 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    energy:              57.72 Wh
    energy-empty:        0 Wh
    energy-full:         57.72 Wh
    energy-full-design:  0 Wh
    energy-rate:         0.6882 W
    voltage:             12.497 V
    time to full:        0 seconds
    time to empty:       0 seconds
    percentage:          100%
    capacity:            93.4423%
    technology:          lithium-ion
  History (charge):
    1242117384	100.000	discharging
  History (rate):
    1242117384	0.688	discharging

Daemon:
  daemon-version:  008
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      yes
  on-low-battery:  yes
Comment 4 J Gallagher 2009-05-12 06:59:02 EDT
Now I've just plugged the ac connecter back in, I first get "Batter is discharging" message from g-p-m icon (bizarrely) at ~15%, then it reverts to the correct charging message, devkit-power shows:


$ devkit-power --dump
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC
  vendor:               
  model:                
  serial:               
  power supply:         yes
  updated:              Tue May 12 11:55:03 2009 (97 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Samsung SDI
  model:                DELL GK4798
  serial:               26104
  power supply:         yes
  updated:              Tue May 12 11:56:35 2009 (5 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              9.4239 Wh
    energy-empty:        0 Wh
    energy-full:         57.72 Wh
    energy-full-design:  0 Wh
    energy-rate:         34.9317 W
    voltage:             11.595 V
    time to full:        1.4 hours
    time to empty:       0 seconds
    percentage:          16.3269%
    capacity:            93.4423%
    technology:          lithium-ion
  History (charge):
    1242125795	16.327	charging
    1242125785	16.096	charging
    1242125775	15.827	charging
    1242125755	15.577	charging
    1242125745	15.346	charging
    1242125725	15.077	charging
    1242125715	14.846	charging
    1242125704	14.981	discharging
  History (rate):
    1242125785	34.932	charging
    1242125745	34.943	charging
    1242125725	34.954	charging
    1242125704	0.011	discharging

Daemon:
  daemon-version:  008
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      yes
  on-low-battery:  no


(I don't know why it says on-battery: yes)
This is all on a Dell Inspiron 1520.

When it charges to 100% I'll post the 3rd requested dump.

I am worried not only about battery damage but also disk damage and data loss, since the shutdowns are immediate and without warning.
Comment 5 J Gallagher 2009-05-12 07:10:23 EDT
I'm still waiting for it to reach 100% but a further problem is that after reinsering th ac power cord the display keeps dimming after about 1min as if it thinks I'm on battery power. grrr
Comment 6 J Gallagher 2009-05-12 09:06:14 EDT
Ok, fully charge to 100%, here's what devkit-power --dump says:

$ devkit-power --dump
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC
  vendor:               
  model:                
  serial:               
  power supply:         yes
  updated:              Tue May 12 11:55:03 2009 (7799 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Samsung SDI
  model:                DELL GK4798
  serial:               26104
  power supply:         yes
  updated:              Tue May 12 13:59:42 2009 (320 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              57.72 Wh
    energy-empty:        0 Wh
    energy-full:         57.72 Wh
    energy-full-design:  0 Wh
    energy-rate:         0.0111 W
    voltage:             12.54 V
    time to full:        0 seconds
    time to empty:       0 seconds
    percentage:          100%
    capacity:            93.4423%
    technology:          lithium-ion
  History (charge):
    1242133171	100.000	fully-charged
  History (rate):
    1242133182	0.011	fully-charged
    1242133171	0.511	fully-charged
    1242133156	2.198	charging
    1242133136	2.220	charging
    1242133116	2.242	charging
    1242133106	2.253	charging
    1242133096	2.287	charging
    1242133076	2.309	charging

Daemon:
  daemon-version:  008
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
Comment 7 Richard Hughes 2009-05-12 10:23:37 EDT
(In reply to comment #3)
> Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
>   updated:              Tue May 12 09:36:24 2009 (8157 seconds ago)

This shows the kernel didn't send us any events for over two hours!

When you're discharging, do you get any output from "udevmonitor --kernel --udev" when you run this as root? You should get an event from the battery every few seconds.

Richard.
Comment 8 J Gallagher 2009-05-12 10:55:11 EDT
[root@localhost ~]# udevmonitor --kernel --udev
the program '/bin/bash' called 'udevmonitor', it should use 'udevadm monitor <options>', this will stop working in a future release
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent


That's after 10mins after ac power is removed, how long should I run for?

Battery still showing as discharging at 100%. This is the same on a Dell Inspiron 1520 and an Acer Aspire One, F11 Preview.

Do you not have any laptops there to test on? I'm guessing this will be widely observed.
Comment 9 Richard Hughes 2009-05-12 11:41:16 EDT
(In reply to comment #8)
> [root@localhost ~]# udevmonitor --kernel --udev
> the program '/bin/bash' called 'udevmonitor', it should use 'udevadm monitor
> <options>', this will stop working in a future release
> monitor will print the received events for:
> UDEV - the event which udev sends out after rule processing
> KERNEL - the kernel uevent
> 
> 
> That's after 10mins after ac power is removed, how long should I run for?

Less than that...

> Battery still showing as discharging at 100%. This is the same on a Dell
> Inspiron 1520 and an Acer Aspire One, F11 Preview.

Right.

> Do you not have any laptops there to test on? I'm guessing this will be widely
> observed.  

I only test on a T61 and a Dell Precision. Both of those give events. :-(
Comment 10 Dan Beard 2009-05-12 18:11:23 EDT
Afternoon, Richard.

Same exists problem in an HP dv9904ca.



Dan
Comment 11 Adrien Bustany 2009-05-17 04:25:41 EDT
Hi
Same problem on Sony Vaio SZ61. Which has a crappy bios, but still, it was working before. Maybe a good solution would be to fall back to polling (acpitool -B works here) if you don't get battery event from the kernels during n minutes...
Comment 12 Richard Hughes 2009-05-17 04:30:54 EDT
Could you try these builds please: http://koji.fedoraproject.org/koji/buildinfo?buildID=102054 -- Thanks.
Comment 13 Adrien Bustany 2009-05-17 05:12:47 EDT
Fixes the problem here :)

Thanks a lot!
Comment 14 J Gallagher 2009-05-17 13:39:07 EDT
Doesn't fix the problem on the Acer Aspire One, still stuck at 100% after removing the ac power.

But does fix it on the Dell Inspiron 1520, so you're getting there.

On removing the AC Power on both machines just 4 events are generated in the 'udevmonitor --kernel --udev' output, and nothing else, so I'm not sure how the battery level is being updated if polling events aren't being generated:


# udevmonitor --kernel --udev
the program '/bin/bash' called 'udevmonitor', it should use 'udevadm monitor <options>', this will stop working in a future release
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1242580456.154123] change   /devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC (power_supply)
UDEV  [1242580456.190760] change   /devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC (power_supply)
KERNEL[1242580457.313432] change   /devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
UDEV  [1242580457.318689] change   /devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0 (power_supply)
...
(nothing else)



Do you require any further logs etc?
Comment 15 J Gallagher 2009-05-17 17:29:39 EDT
This is not good...

My Dell Inspiron just powered off on AC power after briefly displaying a Battery at Critical level message. On reboot the battery shows ~83% charge with 30mins until charged.

That f12 DeviceKit-power rpm looks very suspect.
Comment 16 J Gallagher 2009-05-19 05:55:59 EDT
Just a clarification:

The problem exists only when the AC power is removed at 100% battery level. If I suspend and resume then the battery level is correctly displayed and decreases as expected. If I remove the power at less than 100% charge it is also ok.
Comment 17 Georgi Hristozov 2009-06-02 12:35:43 EDT
The problem is reproducible on my Toshiba Satellite A200-1Z2 with PA3534U battery, using gnome-power-manager-2.26.1-3.fc11.i586. As J Gallagher said, it triggers only when the AC power is removed when the battery is charged at 100%. I'm running gkrellm aswell and it reports the correct percentage.
Comment 18 Georgi Hristozov 2009-06-02 13:40:17 EDT
The koji package fixed the problem here.
Comment 19 Jean-Francois Saucier 2009-06-02 23:22:31 EDT
I can confirm the problem on a fully updated rawhide (as of 2nd june) with a Dell Mini 9 netbook.
Comment 20 Richard Hughes 2009-06-03 03:55:03 EDT
Can you try installing https://admin.fedoraproject.org/updates/F11/FEDORA-2009-5740 and https://admin.fedoraproject.org/updates/F11/FEDORA-2009-5728 and then reboot please. If it fixes things, please report that as positive karma for the update. Thanks.
Comment 21 Łukasz Wojdyła 2009-06-03 16:12:24 EDT
The same problem on HP Pavilion dv6700t us. Nothing change after installed above packages.

It happens only when I use F11. G-P-M in F10 works perfect.
Comment 22 J Gallagher 2009-06-08 09:37:52 EDT
NO, those latest packages do not help on an Acer Aspire One. The same problem remains.

If I remove the ac-power the battery level remains at 100% in gnome-power-manager, and about 2 hours later the machine powers off without any warning, and without any chance to save open documents.

As I have already posted, if I suspend and resume the machine the battery level is then correctly monitored, so your polling at the 100% state is missing something. In F10 the battery is monitored correctly, so I suggest you work out how the logic changed between F10 and F11.
Comment 23 Bradley 2009-06-09 04:03:24 EDT
Doesn't help me either (HP dv6519tx)

DeviceKit-power-008-1.fc11.x86_64
gnome-power-manager-2.26.2-1.fc11.x86_64

The applet also shows the power plug icon on the batter even when its unplugged (not all the time, but mostly), and when I run |dbus-monitor --system| when unplugging I don't get any messages for the AC, even though the sysfs entries change.

In case it matters, the laptop's battery doesn't support reporting the power draw - previous gnome-power-manager versions interpolated from the change in reported watt hours.
Comment 24 Bradley 2009-06-09 04:17:29 EDT
Also, it seems to update if I start X with the AC unplugged, with |devkit-power --dump| updating the battery state every 30 seconds or so.

I tried just restarting dbus but that kills X.
Comment 25 Bug Zapper 2009-06-09 11:31:57 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 26 Steve 2009-06-12 11:11:38 EDT
I've got the same problem here with Fedora 11 (i686), though it doesn't consistently happen.  Running on a Dell Precision M90 laptop.  

I had an incident this morning where my laptop was plugged into AC and then suddenly got the message that the battery level was low and automatically shutdown.

When pulling the AC, the battery icon remains in charging or charged status, despite when going to power history->AC adapter, it says it is *not* online.  This happened a few times but not always.

The screen also dims at the wrong moments sometimes.  That is, things sometimes become reversed in the preferences. e.g. When I pull out the AC and run on battery, then setting the brightness setting in the AC power tab actually changes the brightness (which it shouldn't since I'm running off battery). When I plug AC back in, this slider stops working. But when I go to "on battery power" tab and toggle the 'reduce backlight brightness', it alters the backlight (which it shouldn't since we are on AC).  This doesn't happen all the time but randomly.

I've never seen this behaviour in Fedora 10.
Comment 27 Steve 2009-06-12 11:57:00 EDT
Created attachment 347597 [details]
screenshot of battery icon and statistics

Notice that its been 96 seconds since last refreshed (I already pulled the AC plug out as seen in next screenshot)
Comment 28 Steve 2009-06-12 11:58:35 EDT
Created attachment 347599 [details]
screenshot of battery icon and AC statistics

It can be seen that the AC adapter is not online for a while and the battery icon still shows we are on AC.
Comment 29 hackob 2009-06-12 22:47:44 EDT
I've got the same problem with Fedora 11 (2.6.29.4-167.fc11.i686.PAE) and HP dv6921la.

When battery is low battery icon show that is at 100% charged but it shutdown. After that I plug it again and it shut down again because it thinks that it's unplugged, and go shut down again.

At second power on and power cord plugged it shows the % of charge.
Comment 30 Matthieu Araman 2009-06-17 19:07:41 EDT
Same problem here with Acer Aspire One (the update were pushed to me via gedora update system) so I think they don't correct the problem for me.

It's very stange because (at 100% battery), when I unplug, the contrast get adjusted correctly to not drain battery and resume to bright after I reconnect.
But the applet tells me my battery is discharging when I connect power !

At 100% connected :
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/ACPI0003:00/power_supply/AC
  vendor:               
  model:                
  serial:               
  power supply:         yes
  updated:              Wed Jun 17 23:50:59 2009 (3533 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C0A:00/power_supply/BAT0
  vendor:               Simplo
  model:                GC86508SM60
  serial:               
  power supply:         yes
  updated:              Wed Jun 17 23:50:59 2009 (3533 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              25.4967 Wh
    energy-empty:        0 Wh
    energy-full:         25.4967 Wh
    energy-full-design:  24.42 Wh
    energy-rate:         8.5803 W
    voltage:             12.503 V
    time to full:        0 seconds
    time to empty:       0 seconds
    percentage:          100%
    capacity:            100%
    technology:          lithium-ion

Daemon:
  daemon-version:  008
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   yes



When disconnected
 devkit-power --dump
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/ACPI0003:00/power_supply/AC
  vendor:               
  model:                
  serial:               
  power supply:         yes
  updated:              Thu Jun 18 01:00:07 2009 (256 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             no

Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C0A:00/power_supply/BAT0
  vendor:               Simplo
  model:                GC86508SM60
  serial:               
  power supply:         yes
  updated:              Thu Jun 18 01:04:16 2009 (7 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    energy:              24.7419 Wh
    energy-empty:        0 Wh
    energy-full:         25.4967 Wh
    energy-full-design:  24.42 Wh
    energy-rate:         9.6903 W
    voltage:             12.138 V
    time to full:        0 seconds
    time to empty:       2.6 hours
    percentage:          97.0396%
    capacity:            100%
    technology:          lithium-ion
  History (charge):
    1245279794	97.040	discharging
  History (rate):
    1245279856	9.690	discharging
    1245279825	9.768	discharging
    1245279794	10.068	discharging
    1245279763	9.713	discharging

Daemon:
  daemon-version:  008
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      yes
  on-low-battery:  no
  lid-is-closed:   yes

After reconnecting power :
devkit-power --dump
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/ACPI0003:00/power_supply/AC
  vendor:               
  model:                
  serial:               
  power supply:         yes
  updated:              Thu Jun 18 01:05:24 2009 (15 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/DeviceKit/Power/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/PNP0C0A:00/power_supply/BAT0
  vendor:               Simplo
  model:                GC86508SM60
  serial:               
  power supply:         yes
  updated:              Thu Jun 18 01:05:25 2009 (14 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              25.4967 Wh
    energy-empty:        0 Wh
    energy-full:         25.4967 Wh
    energy-full-design:  24.42 Wh
    energy-rate:         8.5803 W
    voltage:             12.139 V
    time to full:        0 seconds
    time to empty:       0 seconds
    percentage:          100%
    capacity:            100%
    technology:          lithium-ion
  History (charge):
    1245279925	100.000	fully-charged
    1245279887	96.038	discharging
  History (rate):
    1245279925	8.580	fully-charged
    1245279917	9.890	discharging
    1245279887	9.801	discharging
    1245279856	9.690	discharging

Daemon:
  daemon-version:  008
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   yes
Comment 31 Abhishek Chowdhury 2009-06-27 02:58:22 EDT
The same kind of problem is also happening in Compaq Presario CQ40-144 TU.
Comment 32 amturnip 2009-06-27 18:03:01 EDT
The OP's symptoms show up also on my Dell Studio, which has Fedora 11 x86_64 up-to-date with respect to the updates mentioned above (gnome-power-manager-2.26.2-1 and DeviceKit-power-008-1).
Comment 33 Orlando Arias 2009-06-29 20:30:34 EDT
HP dv6775us presenting same issues using gnome-power-manager-2.26.2-1 and DeviceKit-power-008-1.

Forced install of build on post 12 ( http://koji.fedoraproject.org/koji/buildinfo?buildID=102054 ) and it sort of works. The icon updates as it should, but messages are incorrect on gnome-power-manager. Display does not dim as it should when disconnected either. Have yet to test whether or not the low battery actions will kick into effect when the set conditions are met.
Comment 34 Wayne Feick 2009-07-13 17:49:11 EDT
Seeing this on a Dell Precision M65 as well.
Comment 35 Kieran Clancy 2009-07-23 13:27:29 EDT
I'm getting this on a CQ61-115TU as well.

Even though there's this more fundamental problem of the battery status not updating, shouldn't gnome-power-manager notice the change from "online: on" to "online: off" in the line-power and decide it's not on A/C anymore? This fact is obviously not reflected by the "on-battery" property provided by devkit though...

Even if we get this bug fixed soon, I think it would probably be worth putting something in gpm which says "hmmm, I haven't received an update for several minutes. This is bad. I'm going to warn the user, and if possible I will make a conservative guess at the remaining time left given charge history." In this case, if it saw that the line power was off, but the battery was still reporting 100% and not being updated, it could at least warn the user.
Comment 36 Kieran Clancy 2009-07-27 01:52:53 EDT
I think this is definitely a bug in DeviceKit-power.

$ devicekit-power -m
Monitoring activity from the power daemon. Press Ctrl+C to cancel.

(no output)

For what it's worth, HAL properly detects all the power changes on my system.

$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
15:19:16.018: computer_power_supply_battery_BAT0 property battery.remaining_time = 450 (0x1c2)
15:19:16.020: computer_power_supply_battery_BAT0 property battery.charge_level.percentage = 96 (0x60)
15:19:16.022: computer_power_supply_battery_BAT0 property battery.charge_level.current = 45820 (0xb2fc)
15:19:16.023: computer_power_supply_battery_BAT0 property battery.reporting.current = 4128 (0x1020)
15:19:16.025: computer_power_supply_battery_BAT0 property battery.voltage.current = 12581 (0x3125)

(etc...)
Comment 37 Agustin Barto 2009-07-28 13:23:55 EDT
I have the same problem with a Dell Studio 15 (1555). KDE's power management module has a similar problem as well.
Comment 38 Wayne Feick 2009-07-31 14:34:13 EDT
Seems to have been fixed on my Dell Precision M65 (although admittedly I've also replaced the battery recently).
Comment 39 Denis A. Borisevich 2009-08-07 05:33:41 EDT
The same situation on Fujitsu-Siemens Esprimo Mobile U9200.

kernel-2.6.29.6-217.2.3.fc11.x86_64
gnome-power-manager-2.26.3-1.fc11.x86_64
DeviceKit-003-1.x86_64
DeviceKit-power-009-1.fc11.x86_64
Comment 40 Richard Hughes 2009-08-20 07:55:58 EDT
(In reply to comment #38)
> Seems to have been fixed on my Dell Precision M65 (although admittedly I've
> also replaced the battery recently).  

Okay, closing. If you've got a different issue on different hardware, please open a new bug. Thanks.
Comment 41 J Gallagher 2009-08-20 20:19:16 EDT
Why was this closed?

The behaviour in current F11 is still broken on the Acer Aspire One, exactly as described in comment #1 over 3 months ago, no change whatsoever.

gnome-power-manager-2.6.3-1.fc11.i586
DeviceKit-power-009-1.fc11.i586
kernel-PAE-2.6.29.6-217.2.8.fc11.i686
Comment 42 Kieran Clancy 2009-09-06 21:28:19 EDT
Hi -- is there any extra information that could be useful in finding and fixing this bug?

By the way, I think the component for this bug really ought to be changed to DeviceKit-power or something other than gnome-power-manager. Unless the maintainer for gnome-power-manager would be able to introduce some kind of temporary workaround to start polling directly if it stops receiving power events?
Comment 43 J Gallagher 2009-09-07 06:34:58 EDT
This issue is still present in Fedora 12 Snapshot 1. It seems there has been no progress at all. Worryingly,mby battery capacity has now dropped to 64.2% (poor) according to gnome-power-manager. I can't prove that this bug has been a contributing cause, but I'm pretty sure the sudden cutouts at very low battery levels didn't help.

I would advise people not to use fedora 11/12 on affected machines until the problem is resolved

(There was no problem in Fedora 10)
Comment 44 Richard Hughes 2009-09-07 07:51:55 EDT
(In reply to comment #43)
> This issue is still present in Fedora 12 Snapshot 1. It seems there has been no
> progress at all. Worryingly,mby battery capacity has now dropped to 64.2%
> (poor) according to gnome-power-manager. I can't prove that this bug has been a
> contributing cause, but I'm pretty sure the sudden cutouts at very low battery
> levels didn't help.

Umm. I'm sure that cycling the battery whatever the final charge will reduce your capacity over time. If you're worried about the capacity readout, buy a new battery. Batteries are only designed for a couple of hundred charge-discharge cycles anyway.

> I would advise people not to use fedora 11/12 on affected machines until the
> problem is resolved

A joke?

> (There was no problem in Fedora 10)  

Sure, and from Fedora 11 we switched to DeviceKit-power. I suggest you try to find the bug in DeviceKit-power and send a patch to the DeviceKit mailing list. I don't have any similar hardware, and I can't reproduce on any of my machines (6...) here.

Certainly providing detailed output dumps of "devkit-power --dump" and "devit-power --monitor-detail" make things easier to spot for me, but without the hardware it's very hard to debug. Open source relies on people finding bugs and sending patches, not just filing bugs and getting the maintainer to do all the work.

Thanks.
Comment 45 Agustin Barto 2009-09-07 08:42:15 EDT
Could you give us the appropriate steps to generate the logs you need? Thanks.
Comment 46 J Gallagher 2009-09-07 08:42:50 EDT
There are over 5 million acer aspire one owners, I'm surprised that I seem to be the only one who noticed this, I guess the +90% windowsxp penetration figures are genuine. Not really a surprise with alternatives like this OS.

Thanks for the advice to go patch it myself, I guess I'll have to, I hope you're not a paid employee of redhat.
Comment 47 Richard Hughes 2009-09-07 09:24:48 EDT
(In reply to comment #45)
> Could you give us the appropriate steps to generate the logs you need? Thanks.  

You need to gather logs from "devkit-power --dump" and "devit-power --monitor-detail", and try to work out why DeviceKit-power isn't picking up the new state. You can run devkit-power manually using "/usr/libexec/devkit-power-daemon --verbose" as root. The verbose details should help pinpoint the problem.
Comment 48 Richard Hughes 2009-09-07 09:32:10 EDT
(In reply to comment #46)
> There are over 5 million acer aspire one owners, I'm surprised that I seem to
> be the only one who noticed this, I guess the +90% windowsxp penetration
> figures are genuine. Not really a surprise with alternatives like this OS.

Are you trolling? I'm not sure. Either way, if you're unhappy with Fedora 11, I can promise you a full refund of what it cost me to obtain.

> Thanks for the advice to go patch it myself

I didn't say that. I said that you should at least aim to debug the problem yourself, and send patches to the maintainer, which happens to be me. If you send me a patch then everyone else benifits too.

> I hope you're not a paid employee of redhat.  

I am. I'm paid by Red Hat to support RHEL and Fedora, but I can't be expected to treat all Fedora "customers" like RHEL customers. If you file a bug against RHEL, it means you're paying for the services of Red Hat, and then 110% of my energy will go into fixing it as fast as possible, and the other Fedora bugs I'm working on get pushed down the TODO. If you file a bug against Fedora then I'll fix it as soon as I can, but the number of bugs filed greatly outnumbers the bugs I can diagnose, test and fix, even working in the evening. In Fedora I'm maintaining PackageKit, gnome-packagekit, hal, hal-info, and a couple of other small packages. Trust me, I'm working hard to fix bugs as they are filed, but please don't expect to give you a service-level-agreement on bugs that I frequently work on in my spare time.

Rant over.
Comment 49 Agustin Barto 2009-09-07 10:36:50 EDT
I tried to reproduce the problem to generate the logs, but it looks like it's already fixed, at least for my configuration. The only annoying thing is that it'll take a few seconds for GPM to sync up with the AC plug status (this used to work almost instantly with HAL).

I also checked KDE 4.3 power management applet and it's also working fine as well. It updates its status much faster than GPM, and it only takes a couple of seconds to update after a resume.

So, thanks a lot :)

FYI, my box is up to date with updates-testing enabled.
Comment 50 Kieran Clancy 2009-09-07 11:08:55 EDT
Created attachment 359999 [details]
Daemon verbose log file (annotations start with '<---')

I still have this problem, even running with a kernel from updates-testing. I am attaching here the log for the daemon. I have annotated it with comments starting with '<---' on the line to show important events from the following timeline:
- started charging almost full battery
- when the battery was charged, I waited several minutes to see if there were any further messages
- I unplugged the AC and waited a few more minutes for messages
- I plugged the AC back in

A couple of things that stand out to me:

1) devkit-power-daemon regularly gives messages like:
no updates on supply /org/freedesktop/DeviceKit/Power/devices/battery_BAT0 for 30 seconds; forcing update

Why do these forced polls stop when the battery is charged? That seems like a bug if it is designed to poll every 30 seconds if it doesn't get an update.

2) devkit-power-daemon clearly receives the signal that something has happened to the battery_BAT0 device when the AC is unplugged -- why is it not detecting that it is no longer charging?
Comment 51 Kieran Clancy 2009-09-07 11:19:48 EDT
Created attachment 360001 [details]
Monitor log file (annotations start with '<---')

Here's the associated log file from `devkit-power --monitor-detail`. I have made the same annotations as I did in the devkit-power-daemon log.

Here you can see that unplugging the AC caused immediate messages to be sent, but that devkit-power has not properly detected or updated the change in the battery properties.

It has correctly detected that the AC is unplugged though -- there's arguably a (separate) bug in gpm in that it continues to show an icon with the AC plugged in after it receives a notification that the AC is offline (even if it doesn't receive an accurate notification about the battery). It is conceivable that computers may one day differentiate between AC and other non-battery sources (e.g. solar).
Comment 52 J Gallagher 2009-09-07 16:38:13 EDT
I can't tell whether it's a udev or DeviceKit bug. The state in /proc/acpi/battery/BAT1/state is always correct, (is the code expecting BAT0 rather than BAT1 somewhere?)

running udevtrigger manually after removing ac power fixes it (devkit starts reporting events)

DeviceKit and the message bus system is nice and fancy, but it's a shame it don't work too good.

My patch would revert to polling /proc/acpi/battery directly from g-p-m, the old fashioned way, until the shiny new toys are worn in properly.
Comment 53 Richard Hughes 2009-09-07 17:36:01 EDT
(In reply to comment #52)
> I can't tell whether it's a udev or DeviceKit bug. The state in
> /proc/acpi/battery/BAT1/state is always correct, (is the code expecting BAT0
> rather than BAT1 somewhere?)

No, that's not the way it works at all.

> running udevtrigger manually after removing ac power fixes it (devkit starts
> reporting events)

So it sounds like this is a udev/kernel issue then.

> DeviceKit and the message bus system is nice and fancy, but it's a shame it
> don't work too good.

udev doesn't use DBus or DeviceKit. If udev doesn't work, then DeviceKit-power (and thus gnome-power-manager) hasn't a hope.

> My patch would revert to polling /proc/acpi/battery directly from g-p-m, the
> old fashioned way, until the shiny new toys are worn in properly.  

g-p-m has never polled /proc/acpi/battery directly. I think you should check your facts more clearly before raising my blood pressure any higher. Thanks.
Comment 54 J Gallagher 2009-09-07 18:36:32 EDT
I already reported the devkit and udev behaviour way back in May (yes that's right, four months ago), perhaps you should have suggested reassigning the bug to those components back then. 

I'm sorry to bother you poor overworked devlopers with my reports of malfunction, in future I'll ensure to delve into the underlying subsystem code and trace the whole system right back to the kernel before having the nerve to post a bug report in such a amateurish manner.

In the meantime, I'll run a background process which polls a reliable source in /proc/acpi for the battery state, the old fashioned way. Perhaps I'll submit it for inclusion in F12, battery-monitor-that-works.rpm

And please don't claim I'm making unjustified demands on your time/expertise, I have been very patient with this bug report, I haven't expected anything but professionalism, and that doesn't include your action in closing the bug when it clearly hadn't been fixed.
Comment 55 Kieran Clancy 2009-09-07 21:08:29 EDT
(In reply to comment #53)
> (In reply to comment #52)
> > running udevtrigger manually after removing ac power fixes it (devkit starts
> > reporting events)
> 
> So it sounds like this is a udev/kernel issue then.

Please read comment #50 and the attached log file -- devkit-power-daemon is receiving notification of the status change when AC is unplugged, but is seemingly misreading it. There's also a definite bug in devkit-power-daemon in that it stops its 30 second polling for no reason.

As I understand it, udev just tells devkit-power that the device (/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/status in my case) has changed, and it is up to devkit-power to read the relevant device information from there? Is there possibly a race condition between udev telling devkit-power that the device's properties have changed and devkit-power reading those changes?
Comment 56 J Gallagher 2009-09-08 10:48:10 EDT
Yes, I think you got it Kieran Clancy, udev generates an event (correctly) when the ac power is plugged/unplugged. BUT devkit-power fails to record the event reliably when unplugging, it records "fully charged" rather than "discharging" and then assumes the battery is still at 100%, fully charged indefinitely.

Running 'udevadm trigger --subsystem-match=power_supply' (as root) shortly after unplugging the ac power generates a new udev event, which cause devkit-power update the state correctly to "discharging" 

So the bug is in Devkit-power, as suspected (since that's what changed from F10)

1. Perhaps it shouldn't stop polling at 100% Fully Charged state, that seems to be one bug here. (NB udev generates no events except when power is unplugged or plugged back in, devkit-power gets its info from somewhere else (/sys or /proc I guess) so udev is a red-herring here)

2. It's also a bug that devkit-power records the udev unplug event as 'fully-charged' rather than 'discharging'.

Fixing 1 would make 2 less of a problem (you'd just have a 30sec delay after unplugging).
Conversely, fixing 2 would fix 1 for free.


If 2 is a race condition problem, then it's likely seen more on certain platforms (such as the aspire one) than others.

:)

Peace.
Comment 57 J Gallagher 2009-09-08 11:08:45 EDT
New bug submitted against DeviceKit-power

https://bugzilla.redhat.com/show_bug.cgi?id=521874
Comment 58 Dominik 'Rathann' Mierzejewski 2010-02-06 16:44:43 EST
Still happening on fully updated F11/x86_64 on my Toshiba Satellite A300D-15B, although it doesn't happen on my EeePC 901 (F11/i686).
Comment 59 Bug Zapper 2010-04-27 10:14:43 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 60 Marco 2010-06-13 16:41:41 EDT
Still happening on fully updated F13/x86_64 on my fujitsu esprimo mobile d9500
Smolt profile here http://www.smolts.org/client/show/pub_53c70035-962a-4bb1-83ca-58e45be28019
Comment 61 Bug Zapper 2010-06-28 08:28:00 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 62 Bradley 2010-07-03 04:22:56 EDT
I still see this, on F13 - unplug the power cable, and the g-p-m battery icon still has the plug.
Comment 63 Vic Ricker 2010-08-22 12:25:18 EDT
I have the same problem on System 76 Pangolin Performance running F13.  acpi_listen reports nothing, no events from the battery, no events when the lid closes/opens.  /proc/acpi/battery/BAT0/state shows the proper state, however.
Comment 64 moondrake 2011-01-16 10:36:32 EST
Interestingly, I have this bug even on a powerpc platform. It worked fine with hal, but upower does not properly report the change to discharging.

I doubt kernel people will fix this as they pass the hardware event when it occurs, as explained by Matthew in 521874. It seems a sound policy to me.

So it is a devicekit/upower bug. 

Richard, it has been assigned to you for a long time. Are you actually doing something to get it fixed? I can probably make a patch for upower, if it has a chance to get applied.
Comment 65 Peter Molnar 2011-02-26 12:22:56 EST
I am still experiencing this bug on FC14, on a HP dv1066. Exact same symptoms as #62.
Comment 66 Richard Hughes 2011-02-28 04:58:08 EST
(In reply to comment #64)
> Interestingly, I have this bug even on a powerpc platform. It worked fine with
> hal, but upower does not properly report the change to discharging.

I've not got any PPC machines to play with anymore.

> Richard, it has been assigned to you for a long time. Are you actually doing
> something to get it fixed? I can probably make a patch for upower, if it has a
> chance to get applied.

Well, I can't reproduce the problem. If somebody makes a patch to fix it, I'll for sure review it and apply it if it makes sense.

Richard.
Comment 67 moondrake 2011-02-28 05:21:15 EST
Well, it seems to me as it is some difference in opinion on whether the kernel driver should send signals that the battery starts discharging. The easy way is to add (at least the option to) poll the battery even when full. 

For powerpc currently the kernel pmu battery driver does not know when the battery starts discharging. However, the old pmu driver is polling the pmu every 2 seconds or so, so in theory it could probably do what is required. However, that driver is very ugly (and does many things beside batteries) and i think pmu_battery was created to move away from the big pmu driver. Polling the pmu /again/ in pmu_battery is probably bad (IIRC there were bugs in the past with accessing it too often). So if upower would continue to read the battery every 30 secs even when full, it would solve the problem on powerpc. I can try to make a patch for this maybe next weekend (quite busy atm).

For the x86 people with broken hardware or with kernel drivers that for some reasons do not report discharging correctly this would also help. But I guess you would be against polling all the time for everyone. Perhaps a quirk option or something can help? That would solve it for everyone including exotic platforms.
Comment 68 Richard Hughes 2011-02-28 07:56:36 EST
(In reply to comment #67)
> Well, it seems to me as it is some difference in opinion on whether the kernel
> driver should send signals that the battery starts discharging. The easy way is
> to add (at least the option to) poll the battery even when full. 

The kernel needs to send an event to userspace. Polling in userspace actually increases the power drawn on the batteries, which is the very thing we're trying to monitor.

> So if upower would continue to read the battery
> every 30 secs even when full, it would solve the problem on powerpc. I can try
> to make a patch for this maybe next weekend (quite busy atm).

No, I think this belongs in the kernel.

Richard.
Comment 69 J Gallagher 2011-02-28 12:42:10 EST
It's not a kernel bug, the problem was identified in https://bugzilla.redhat.com/show_bug.cgi?id=521874, where it was pointed out that checking POWER_SUPPLY_ONLINE flag was the correct way to check if the ac power was connected. (POWER_SUPPLY_STATUS or POWER_SUPPLY_TYPE aren't reliable)
Comment 70 moondrake 2011-02-28 22:38:01 EST
>Polling in userspace actually increases the power drawn on the batteries

Pay attention, we are talking about polling once in 30 seconds when the power is /plugged/. 

> No, I think this belongs in the kernel.

Right, you are being counter productive now, this issue is simply not going away. Regardless of what is the best thing to do (the post above seems to suggest that it is not so clear cut), this is a distro-bugzilla, not an upstream Upower one. If an option in upower could work around a kernel bug (if it is one) and fix issues on various platforms on released versions of this distro than it is the right thing to do while changes to various kernel drivers are pending.

There has been a big push to streamline powermanagement across platforms to make it uniform and the same. The end result is that people using non-x86 mostly disable it and use old (and often bad) daemons like pbbuttonsd anyway because they *work*. A more pragmatic approach for devkit would go a long way to improve usability for everybody. While at the same time keeping pressure on kernel folks to make sure at least the new drivers do the right thing.

Just blaming each other is getting us nowhere. I installed debian and going to push a fix into that distro as I do not have to deal directly with upstream.
Comment 71 Bug Zapper 2011-06-02 14:06:19 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 72 Bug Zapper 2011-06-27 10:11:44 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.