Hide Forgot
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090507 As soon as i unplug the laptop (HP nx7000) from ac the message "laptop battery critically low" appears even thoug the battery is fully charged. Since the default setting of gnome-power-manager in such is to shut down the laptop it is impossible to use the laptop on battery until the setting is changed or the computer is on ac again. Reproducible: Always Steps to Reproduce: 1. Unplug the laptop from ac. Actual Results: When the configuration for "When battery power is critically low" is set to "do nothing" the gnome-power-manager exhibits the following behaviour: 1. Message "laptop battery critically low" appears. Power History -> Laptop battery shows a "Time to empty" of about 2 minutes (see screenshot 1) 2. After a few seconds the "Time to empty" changes to 1.7 hours which is about right for a fully charged battery when the computer is mostly idle (see screenshot 2) 3. After about 1 minute the message "laptop battery critically low" appears again and the "Time to empty" changes back to 2 minutes. Point 2 and 3 are repeated until the battery is out of juice. Expected Results: gnome-power-manager should do nothing until the battery charge is realy low. Before I installed Fedora 11 I used Fedora 9 on this laptop. I cannot say if Fedora 10 already has the same problem on this hardware.
Created attachment 350157 [details] Screenshot 1
Created attachment 350158 [details] Screenshot 2
Created attachment 350160 [details] Screenshot 3
Does installing the latest gnome-power-manager and DeviceKit-power packages in updates-testing (and then rebooting...) fix the problem?
Installed gnome-power-manager-2.26.4-1.fc11.i586 and DeviceKit-power-010-0.3.20090810git.fc11.i586 Problem is still exists.
I upgraded to F12 -> same problem.
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
Upgraded to F13. Problem is still there.
I have the same problem with my MSI Wind U100 (MS-N011) netbook. I use F13 in 32 bits (actually 2.6.33.5-124.fc13.i686.PAE kernel).
Having the same issue with Fedora 13 from fresh install. as soon as AC power is disconnected, I get a warning message about battery critically low and goes into hibernation. No such problem with the fedora 13 LiveCD KDE version.
I have had this problem from a very long time. Some folks on ubuntu have noted that this problem might have something to do with upower. I typed this python script first: import os while (1): os.system("upower -d") and ran it, redirecting the output into a file. As it was running, I unplugged my AC cable. As expected, my laptop suspended. After waking up my laptop, I stopped it and took a look at the output file. The problem seems to be with the energy-rate. I ran "grep energy-rate:" on the output file and this is what I got: [dilip@Blackpearl experiments]$ grep energy-rate upower.out energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 6.0495 W energy-rate: 0 W energy-rate: 0 W energy-rate: 0 W energy-rate: 0 W energy-rate: 0 W energy-rate: 0 W energy-rate: 0 W energy-rate: 0 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 0.4884 W energy-rate: 4.662 W energy-rate: 4.662 W energy-rate: 4.662 W energy-rate: 4.662 W energy-rate: 4.662 W energy-rate: 4.662 W energy-rate: 4.662 W energy-rate: 4.662 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 5.6832 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W energy-rate: 6.7488 W [dilip@Blackpearl experiments]$ You can clearly see whats happening when I unplug the power supply. Hope this helps. Please let me know if you need any more details. Regards. Dilip
(In reply to comment #11) > I have had this problem from a very long time. Some folks on ubuntu have noted > that this problem might have something to do with upower. UPower just proxies the values from the kernel. > You can clearly see whats happening when I unplug the power supply. I really can't that's just a list of rate values. Could you get the verbose output from upower please: (as root) killall upowerd /usr/libexec/upowerd --verbose and then *attach* the output to this bug please, showing the disconnect, suspend and then resume. Thanks.
Sorry, I wasn't being very clear. Anyway, something seems to be wrong. When I tried /usr/libexec/upowerd --verbose this is what happened: TI:19:01:07 FI:egg-debug.c FN:egg_debug_post_parse_hook,415 - Verbose debugging 1 (on console 1) TI:19:01:07 FI:up-main.c FN:up_main_acquire_name_on_proxy,83 - Failed to acquire org.freedesktop.UPower TI:19:01:07 FI:up-main.c FN:main,175 - Could not acquire name; bailing out [root@Blackpearl experiments]# /usr/libexec/upowerd --verbose TI:19:01:15 FI:egg-debug.c FN:egg_debug_post_parse_hook,415 - Verbose debugging 1 (on console 1) TI:19:01:15 FI:up-main.c FN:up_main_acquire_name_on_proxy,83 - Failed to acquire org.freedesktop.UPower TI:19:01:15 FI:up-main.c FN:main,175 - Could not acquire name; bailing out If anyone can help me fix this, I can try again and get the output. Thanks. -Dilip.
(In reply to comment #13) > If anyone can help me fix this, I can try again and get the output. Thanks. You need to do "killall upowerd" first.
Created attachment 471316 [details] upowerd --verbose log I see the same thing on F14 too. Sometimes it manages to calculate the correct battery time remaining prior to shutting down / hibernating. Attached is my upowerd --verbose log before it hibernates.
Seeing this here on an Atom tablet (presumably the same as Bug 609081?), under Fedora 15 beta. Any progress on getting this fixed (aside from working around it with gconf settings)? Is there any info I can provide for my hardware?
OK: In my case, I believe this to be a BIOS issue, specifically the "negative s16 current" issue found on some Acer notebooks and addressed in Kernel bug 13687 (see https://bugzilla.kernel.org/show_bug.cgi?id=13687 ). To test this, I modified driver/acpi/battery.c in the kernel source. Somewhere in it, there's a function static void acpi_battery_quirks(struct acpi_battery *battery) { if (dmi_name_in_vendors("Acer") && battery->power_unit) { set_bit(ACPI_BATTERY_QUIRK_SIGNED16_CURRENT, &battery->flags); } } and commented out 'dmi_name_in_vendors("Acer") &&' in the if(). With *this* kernel running, I no longer get spurious "critically" low messages. How did I know this? Well, when running on power take a look at /sys/class/power_supply/BAT0/current_now. On battery, it shows a reasonable 931000 µA. Now, when AC is plugged in and the battery is charging ON A STOCK KERNEL, this value changes to 65336000 µA (if I recall the number correctly). This is clearly ludicrous, and is called by bad handling of a 16-bit current register. Maybe what's happening in this case is, when the AC is unplugged, g-p-m is using this high current to estimate remaining time (i.e., 3 minutes). On a modified kernel, current_now is somewhat more sedate with AC attached (some 200000 µA); I presume this is the charging current. I am going to report a new bug against kernel (both here and at kernel.org) documenting this. Seems the quirk needs broadening. For gnome-power-manager: - Perhaps g-p-m could add a current plausibility check and warn the user that their BIOS is having a laugh? - Sometimes I now get ludicrously long battery life estimates (e.g. 15h) as AC is unplugged. This seems consistent with g-p-m using the value of current_now (i.e., charging current) to estimate usage. I suggest g-p-m waits a few seconds for things to settle when on battery power before taking a reading of current_now and making an estimate.
I have a Dell Mini 10; with my laptop plugged in, I get: [cozzy@cozzy-nb ~]$ cat /sys/class/power_supply/BAT1/current_now 37168000 Which seems to actually be the power (~37 W). Anyway, to work around the issue, I set the gconf key /apps/gnome-power-manager/general/use_time_for_policy to false and it uses a percentage threshold rather than a time threshold, making the point moot. -Cosmin
I am not sure if I should open a new bug or not but my scenario is similar on a System 76 Starling Netbook Model star1 using F15. However, this *only* occurs if I suspend my laptop to RAM while unplugged and plug in the power *while the computer is still suspended*. After that, subsequent attempts to remove the power are met with panicky notifications that the system is about to hibernate ... although it only seems to hibernate prematurely if the battery is fairly drained. My steps to reproduce: 1) Unplug power from laptop 2) Suspend to RAM 3) Plug power into laptop 4) Wake up from Suspend to RAM 5) Unplug power from laptop Results: Hibernation warning even though power applet reports high percentage of battery left (94% in my current test case) Could the original reporter and subsequent confirmers check if this is the specific scenario that they are seeing this as it might point to a specific fix or it might be that this is a separate issue (maybe a bad power drain estimate due to a power supply event missed while suspended ... in which case I will open a separate bug). Thank you.
Hello Michael. I tried this on my Acer Aspire One netbook running Fedora 15. My laptop did not produce any hibernation warning. Here is what happened in my laptop. 1. Plug power into laptop (battery 74%) 2. Unplug power 3. Laptop suspends to RAM by itself 4. Plug power into the laptop 5. Wake up from suspended state 6. Unplug power 7. Laptop suspends to RAM again This happened every time I tried this. Does anyone else see the same response? -Dilip
Hello everyone. I notice that my laptop does not suspend to ram if I unplug the power after switching to a terminal (Alt + Ctrl + F2) on my Fedora 15. Steps to reproduce: 1. Plug power to laptop 2. Switch to a console terminal (Ctrl + Alt + F2) 3. Unplug power 4. Return to Gnome (Alt + Ctrl + F1 in my Fedora 15) Results: Does not suspend to RAM. Is anyone else able to observe the same behaviour or is this just my laptop? -Dilip
(In reply to comment #21) > Hello everyone. > > I notice that my laptop does not suspend to ram if I unplug the power after > switching to a terminal (Alt + Ctrl + F2) on my Fedora 15. > > Steps to reproduce: > 1. Plug power to laptop > 2. Switch to a console terminal (Ctrl + Alt + F2) > 3. Unplug power > 4. Return to Gnome (Alt + Ctrl + F1 in my Fedora 15) > > Results: Does not suspend to RAM. > > Is anyone else able to observe the same behaviour or is this just my laptop? > > -Dilip I do not see this. My netbook suspends fine after the above process. It didn't suspend when closing the lid only once ... just yesterday though. I cannot figure out why it didn't that one time. Might have been in some weird state after cycling though those bug-inducing steps from comment 19.
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
Created new bug 710226 to track my separate issue that may or may not be related to this one but it is relevant to Fedora 15 and this bug is about to be auto-closed.
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.
This is still happening with Fedora15. Dell latitude E6320
Bug has returned for me with g-p-m 3.0.2-2.fc15 update, even with kernel patched for correct current. More in this bug's clone.