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
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
What does "devkit-power --dump" say when the battery is charging, is fully charged and also discharging? Thanks.
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
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.
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
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
(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.
[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.
(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. :-(
Afternoon, Richard. Same exists problem in an HP dv9904ca. Dan
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...
Could you try these builds please: http://koji.fedoraproject.org/koji/buildinfo?buildID=102054 -- Thanks.
Fixes the problem here :) Thanks a lot!
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?
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.
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.
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.
The koji package fixed the problem here.
I can confirm the problem on a fully updated rawhide (as of 2nd june) with a Dell Mini 9 netbook.
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.
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.
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.
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.
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.
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
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.
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)
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.
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.
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
The same kind of problem is also happening in Compaq Presario CQ40-144 TU.
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).
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.
Seeing this on a Dell Precision M65 as well.
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.
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...)
I have the same problem with a Dell Studio 15 (1555). KDE's power management module has a similar problem as well.
Seems to have been fixed on my Dell Precision M65 (although admittedly I've also replaced the battery recently).
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
(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.
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
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?
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)
(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.
Could you give us the appropriate steps to generate the logs you need? Thanks.
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.
(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.
(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.
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.
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?
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).
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.
(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.
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.
(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?
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.
New bug submitted against DeviceKit-power https://bugzilla.redhat.com/show_bug.cgi?id=521874
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).
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
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
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.
I still see this, on F13 - unplug the power cable, and the g-p-m battery icon still has the plug.
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.
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.
I am still experiencing this bug on FC14, on a HP dv1066. Exact same symptoms as #62.
(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.
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.
(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.
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)
>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.
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
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.