Action on critical battery isn't triggered
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| gnome-power |
Fix Released
|
Medium
|
||
| gnome-power-manager (Baltix) |
Undecided
|
Unassigned | ||
| gnome-power-manager (Ubuntu) |
Medium
|
Martin Pitt | ||
| Karmic |
Medium
|
Martin Pitt |
Bug Description
Binary package hint: gnome-power-manager
I am using Gutsy Tribe 5. On Feisty, everything works as expected.
I am using a Dell Inspiron 510m. Apparently it has two battery bays, although I have only ever had one battery in it.
I have set the preference to shut down on critical and to hibernate on critical. In both cases it just runs down to nothing and powers off.
Related branches
MattJ (mwild1) wrote : | #1 |
Sitsofe Wheeler (sitsofe) wrote : | #2 |
(Could be seen as related to Bug #64751 / Bug #61201 )
Sitsofe Wheeler (sitsofe) wrote : | #3 |
(Might also be related to Bug #113244 )
Oliver Grawert (ogra) wrote : | #4 |
can you check if thats still the case with the most recent version of gnome-power-manager ?
Changed in gnome-power-manager: | |
status: | New → Incomplete |
Fabien Lusseau (fabien-beosfrance) wrote : | #5 |
Same with the last version, see the Bug #136777
It as been nominated for gutsy, but it as been marked as duplicate of this ... -> please nominate it for gutsy !
This bug is critical and confirmed, not incomplete ...
Changed in gnome-power-manager: | |
status: | Incomplete → Confirmed |
MattJ (mwild1) wrote : | #6 |
Yes, same issue with the latest version.
I think I can maybe offer some explanation for (at least my) part of the problem.
The critical_action in gconf is set to 120 seconds of time remaining. As I wrote previously the lowest my remaining time indicator in the g-p-a tooltip never goes below 5 minutes... it disappears after that (it also seems to go in 5-minute steps, ie. 10min, 5min, disappeared). So I am guessing it never internally reaches 120 seconds.
I changed the critical action to 300 seconds (5 minutes), no luck. However when I set it to 360, it now works as it should, hibernating when there are 6 minutes remaining. Switching to percentage-based thresholds is also a workaround for the problem.
This bug is critical as Fabien said, simply because it exists in the default setup and has a very high risk of data loss for unsuspecting users.
Fabien Lusseau (fabien-beosfrance) wrote : | #7 |
Hurry up !!!!
You can't forget this critical bug !!
Jerry McVey (jerrymcvey) wrote : | #8 |
I can confirm this happens on a Thinkpad R50p. Laptop will suspend and hibernate manually, and suspend on lid close (my setting) so power management seems to work. However, saw this problem in the RC and earlier series and wanted to check if it was fixed in the final. In a test run on my system, GPM reported that the battery was critical and it would hibernate in a few minutes (this with under 5 minutes of power left). I was expecting it to do so but instead it simply allowed the entire system to crash. The BIOS power alarm came on as well but GPM didn't do anything other than warn it was going to hibernate, then failed to do so.
Chad Bernier (berniercr) wrote : | #9 |
So that's any easy fix. Just switch it to default to percentages rather than percent. Is there something wrong with that? IT's probably easier than fixing the time reported issue. mine is now set to be critical at 3 and hibernate at 2%, the default percentages. Seeing how i get somewhere between 2-3 minutes per percent when using my big battery, and light load as typical, and I don't use the small one often, this seems very reasonable.
I can't believe one check box fixes this problem, yet no fix has been released. Now i have to fix my bad attempt at fixing this problem. My computer has been hibernating itself very often, haha.
Asus Z99H
suspend_to_ram works but suspend_to_disk didn't work on edgy and feysty either (gutsy also :( )
I can see, that battery level is critical, in power-management applet on panel
Where (in what exactly files should I change the settings?)
I found /etc/laptop-
# Should laptop mode tools perform auto-hibernation?
ENABLE_
AUTO_HIBERNATIO
AUTO_HIBERNATIO
I tried to set
ENABLE_
AUTO_HIBERNATIO
AUTO_HIBERNATIO
but no luck :\
still I found sth about hibernate /etc/default/
# Set the following to "platform" if you want to use ACPI to shut down
# your machine on hibernation
HIBERNATE_
costales (costales) wrote : | #11 |
Same problem in nx7300 HP laptop (1,8 Mhz, 1GB Ram, 1GB Swap, 80 GB HD) :(
I can hibernate in System / Quit.
But It doesn't hibernate when the battery is critical.
I change the Configuration Editor changed time for policy, and the percentages. Not works :(
Version: Ubuntu 7.10 Final.
I can confirm this bug is critical.
Changed in gnome-power-manager: | |
importance: | Undecided → Critical |
Bart Samwel (bart-samwel) wrote : | #14 |
Note that the laptop-mode.conf settings won't help. Ubuntu has taken the laptop-mode-tools package from Debian, ripped its guts out (the part that listens on ACPI events) and failed to mention this anywhere in the config files. By default, the whole thing is even disabled. Again, no mention in the laptop-mode.conf config file. You have to go into /etc/default/
ubuntu_demon (ubuntu-demon) wrote : | #15 |
to Bart Samwel :
Does Ubuntu's default laptop-mode set commit intervals and such things back to the default to prevent losing 10 minutes of data when battery is critical ? If not we should definitely file a bug for that.
Andreas Fey (info-andreas-fey) wrote : | #16 |
Same on IBM Thinkpad R60 and R60e - when battery is low, nothing happens except the textual notice from power manager. The PC does not shutdown and runs until the battery is absolutely empty.
The same here, my laptop doesn't shutdown when the battery is critical. I have tried to search for those gconf keys that you mention here and in my system they don't exist, at least battery_critical_*.
Anyone can help us?
Hi
I have been checking again all the gconf keys and now it's working. The problem is that the keys are different named, so I couldn't find them. The solution has been to unchecked the use_time_policy. I don't know why is not working with the time policy, but now everything is running.
The thresholds are in a sub folder and there you can change them as you want (time policy and percentage policy thresholds).
Daniel
Andreas Fey (info-andreas-fey) wrote : | #19 |
Hi,
i recently unchecked the gconf key
gnome-power-manager -> general -> use_time_for_policy
on my Thinkpad R60 and R60e; now it seems to work again.
I did this utilizing the application gconf-editor (for those who want to change this value, too).
Andreas
nichri (nichri) wrote : | #20 |
I own a Lenovo 3000V100 which I have now upgraded to Gutsy and faced the same problem (while this was not a problem in the prev version).
I read your comments and noticed that in the file /etc/laptop-
I changed this as below and I am now waiting for my battery to drain to see if it works:
# HIBERNATE_
HIBERNATE_
FYI the /etc/acpi/
I will let u know of the outcome however you can try it yourselves as well.
Nicolas
nichri (nichri) wrote : | #21 |
Unfortunately no luck on the above; the laptop went dead as usual... :(
Ted Gould (ted) wrote : | #22 |
Could you please try to see if the gnome-power-manager commands working for you on your laptop? Specifically:
gnome-power-cmd.sh suspend
That sends the DBUS message to the GNOME Power Manager and uses it's suspend routine.
Daniel Lombraña González (teleyinex) wrote : Re: [Bug 135548] Re: [Gutsy] Action on critical battery isn't triggered - regression | #23 |
I have tried it and it's working, but I'm using s2disk instead of linux
kernel suspend commands because they don't work on my laptop.
Daniel
On Dec 20, 2007 12:54 AM, Ted Gould <email address hidden> wrote:
> Could you please try to see if the gnome-power-manager commands working
> for you on your laptop? Specifically:
>
> gnome-power-cmd.sh suspend
>
> That sends the DBUS message to the GNOME Power Manager and uses it's
> suspend routine.
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
·······
PhD Candidate
Cátedra Ceta-Ciemat de la Universidad de Extremadura
Universidad de Extremadura
·······
Por favor, NO utilice formatos de archivo propietarios para el
intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT, CSV
o cualquier otro que no obligue a utilizar un programa de un
fabricante concreto para tratar la información contenida en él.
·······
Nicola Gallo (nicola-ga) wrote : Re: [Gutsy] Action on critical battery isn't triggered - regression | #24 |
same bug on dell xps m1330 with gutsy updated daily.
scicane (nicos-scicane) wrote : Re: [Bug 135548] Re: [Gutsy] Action on critical battery isn't triggered - regression | #25 |
Mine also works with either suspend or hibernate; it also works with the
laptop lid closed (goes to sleep mode).
The problem is with sleep when on battery or hibernate when on critical
battery.
On 20/12/2007, Ted Gould <email address hidden> wrote:
>
> Could you please try to see if the gnome-power-manager commands working
> for you on your laptop? Specifically:
>
> gnome-power-cmd.sh suspend
>
> That sends the DBUS message to the GNOME Power Manager and uses it's
> suspend routine.
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Nicos Christodoulou
SciCane Ltd.
1A Technis Str.
CY-3055 Limassol
Tel. (+357)70006670
Fax (+357)25821239
<email address hidden>
<email address hidden>
This email and its attachments may be confidential and are intended solely
for the use of the individual to whom it is addressed. Any views or opinions
expressed are solely those of the author and do not necessarily represent
those of Scicane Ltd.
If you are not the intended recipient of this email and its attachments, you
must take no action based upon them, nor must you copy or show them to
anyone.
Please contact the sender if you believe you have received this email in
error.
Same problem here with Gutsy on a Quanta mw1.
Doing:
killall -9 gnome-power-
when battery has 11% of power.
as seen in:
http://
http://
got me the file attached.
Should get low power notification at 10%, critical at 3% and action (shutdown) at 2%, but no notification with anyone and no action too.
But executing "gnome-power-cmd.sh shutdown" in a terminal works perfect.
Hope this could help.
Kaur Männamaa (kaurman) wrote : | #27 |
I messed with /etc/laptop-
My config:
#
# Should laptop mode tools perform auto-hibernation?
#
ENABLE_
#
# The hibernation command that is to be executed when auto-hibernation
# is triggered.
#
HIBERNATE_
#
# Auto-hibernation battery level threshold, in percentage of the battery's
# total capacity.
#
AUTO_HIBERNATIO
#
# Enable this to auto-hibernate if the battery reports that its level is
# "critical".
#
AUTO_HIBERNATIO
Gnome-power manager notifies me about the low power and critical status of the battery so maybe it (and not laptop mode) starts the hibernation. In that case the bug has probably been fixed...
Timmie (timmie) wrote : | #28 |
I have the same problem.
Notebook: Asus Z92J (kinda AJ6 series).
I am really missing a comment from the developers here. This is a data loss issue!
scicane (nicos-scicane) wrote : Re: [Bug 135548] Re: [Gutsy] Action on critical battery isn't triggered - regression | #29 |
I used the gconf-editor to turn 'use time-policy' to false as mentioned in
previous comment and the issue was sorted out for me (i.e. no sleeping
automatically on battery and not hibernating on critical battery). However
another minor problem is that when it turned to sleep while left unattended
in battery mode, it went to hibernate as soon as I turned it on. Some
configuration must be there to tell hibernate not to count time when in
sleep mode.
FYI, I own a Lenovo 3000V100.
cheers,
Nicolas
On 14/01/2008, Tim <email address hidden> wrote:
>
> I have the same problem.
> Notebook: Asus Z92J (kinda AJ6 series).
>
> I am really missing a comment from the developers here. This is a data
> loss issue!
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
--
Nicos Christodoulou
SciCane Ltd.
Changed in gnome-power-manager: | |
assignee: | nobody → ted-gould |
The same problem on HP nx8220, Gutsy.
No notifications, no actions, notebook discharges to death, even if I unset "use time for policy".
On feisty everything went perfectly.
nmcaramelo (nmcaramelo) wrote : | #31 |
Same problem on Lenovo T61, Gutsy Gibbon.
I have all the notifications but no actions are performed by Power Manager. If I try the commands manually they work.
Cheers,
nmtsunami
scicane (nicos-scicane) wrote : Re: [Bug 135548] Re: [Gutsy] Action on critical battery isn't triggered - regression | #32 |
check earlier comments about gconf-editor changes.
I managed to make it work through that.
chees,
Nicos
On 27/01/2008, nmcaramelo <email address hidden> wrote:
> Same problem on Lenovo T61, Gutsy Gibbon.
>
> I have all the notifications but no actions are performed by Power
> Manager. If I try the commands manually they work.
>
> Cheers,
> nmtsunami
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
Jakob Unterwurzacher (jakobunt) wrote : Re: [Gutsy] Action on critical battery isn't triggered - regression | #33 |
I also experience this bug, on a Benq Joybook R55.
Unchecking use_time_for_policy did *not* fix this for me.
Raising the time thresholds and checking use_time_for_policy did not either.
I guess confirming the upstream bug ( http://
Changed in gnome-power: | |
status: | Unknown → New |
Spyros Theodoritsis (madmetal) wrote : | #34 |
i have the same problem from gutsy beta until now.
gnome power shows 3 batteries although i have only one and the other two appearing batteries are empty.
so when the battery is low system doesn't suspend as i have set.
system is Compaq Armada E500 laptop with Gutsy latest updates.
appearing to have 3 batteries instead of one
madmetal@
present: no
madmetal@
present: no
madmetal@
present: yes
capacity state: ok
charging state: charged
present rate: 0 mW
remaining capacity: 43000 mWh
present voltage: 16626 mV
maris382 (maris382) wrote : | #35 |
I have the same problem - on an LG T1 Express Dual.
If use_time_for_policy is true it doesn't hibernate before the computer shuts off hard (the power-manager applet runs down to 0% charge and stops showing time estimates before that happends)
Setting use_time_for_policy to false solves the problem.
I have set my system to stand by if power is critical. However, it does nothing, the battery just runs out. I have Hardy Heron, can this be the same bug or should I look elsewhere?
nmcaramelo (nmcaramelo) wrote : Re: [Bug 135548] Re: [Gutsy] Action on critical battery isn't triggered - regression | #37 |
It's the same bug.
This bug have's two problems related, the recognition of the battery status,
it recognizes two or more battery's when you have only one (solved with
Hardy Heron Alpha5 release), and it doesn't trigger any action when the
battery is in critical status (not solved yet).
I hope for a correction as quick as possible.
Best regards,
nmcaramelo
On Fri, Feb 22, 2008 at 10:07 AM, ThomasNovin <email address hidden> wrote:
> I have set my system to stand by if power is critical. However, it does
> nothing, the battery just runs out. I have Hardy Heron, can this be the
> same bug or should I look elsewhere?
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
Thomas N (konstigt-deactivatedaccount) wrote : Re: [Gutsy] Action on critical battery isn't triggered - regression | #38 |
I've written in my duplicate bug that the workaround with use_time_for_policy did not work for me. This was only true before I had rebooted. Now I got notification about low power, critical power and then also a automatic suspend. Wow! :)
Chad Bernier (berniercr) wrote : Re: [Bug 135548] Re: [Gutsy] Action on critical battery isn't triggered - regression | #39 |
good, you always should reboot. linux will let you reboot just the relevant
portion of the system, but only if you know how. Why do you want it to
suspend on low power? It will just continue to draw power in suspend mode.
It'll then turn off without shutting down properly. I'd rather set the
limits lower and use hibernate mode. It's not like the computer can do
anything useful while suspended. I pretty much never use suspend because it
stops downloads.
On Sun, Feb 24, 2008 at 11:49 AM, ThomasNovin <email address hidden> wrote:
> I've written in my duplicate bug that the workaround with
> use_time_for_policy did not work for me. This was only true before I had
> rebooted. Now I got notification about low power, critical power and
> then also a automatic suspend. Wow! :)
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
Sense Egbert Hofstede (sense) wrote : Re: [Gutsy] Action on critical battery isn't triggered - regression | #40 |
The same kind of errors are coming back in hardy: bug #194719 and gutsy: bug #154003
Although they're not exactly the same they reporters are complaining about double batteries. Could it have the same cause?
Changed in gnome-power-manager: | |
status: | Confirmed → Fix Released |
Changed in gnome-power: | |
status: | New → Fix Released |
Changed in gnome-power-manager: | |
status: | Fix Released → Confirmed |
Changed in gnome-power-manager: | |
status: | Confirmed → Incomplete |
Changed in gnome-power-manager: | |
status: | Incomplete → Confirmed |
Changed in gnome-power-manager: | |
status: | Confirmed → Fix Released |
arturj (arturj-freenet) wrote : | #103 |
Using Inrepid I still have the problem on a Thinkpad T43 (g-p-m version is 2.24.0-0ubuntu8). I think the problem is, that g-p-m recalculates remaining time and percentage only if battery changes by 1%. Let me explain this:
- Reading /proc/acpi/
- Now g-p-m only recalculates if battery changes by 1% no recalculation happens for that time. As 4% is calculated to 10-15 minutes remaining time no automatic shutdown is triggered, no matter if use_time_for_policy is true or false, as both thresholds are much lower (2% or 120 seconds).
- Near complete crash of the system the battery state begins to change again, but drops from 1800 mWh to near ZERO. The remaining time is not enough to let g-p-m trigger anything and the system crashes.
Suggestions: raise all thresholds or change the way g-p-m is polling or beeing notified about battery state changes.
arturj (arturj-freenet) wrote : | #104 |
Addendum: things seem to be more complicated.
Using "use_time_
Disabling "use_time_
Generally there is additionally a problem when my battery suddenly dropps from 3% to 0% directly. In this case g-p-m does not react to this change and again noting happens. So if 3% was calculated to 5 minutes remaining time than jumping to 0% directly g-p-m still shows 5 minutes remaining time.
arturj (arturj-freenet) wrote : | #105 |
Tested in Ubuntu Intrepid - not working!
Changed in gnome-power-manager: | |
status: | Fix Released → In Progress |
also still problem on Intrepid with Asus Z99H
martin (mbvlist) wrote : | #107 |
Same problem on a NEC P550. I hope changing the GConf-value helps.
Guido Conaldi (guido-conaldi) wrote : | #108 |
I can confirm the regression on my ubuntu up-to-date 8.10 64bit on a dell xps m1330.
I can also confimrm the behaviour described by arturj in comment 104. For me as well raising the critical action threshold to at least 360 seconds was working as a workaround in ubuntu 8.04.
No bios updates happend in the mean time.
Endolith (endolith) wrote : | #109 |
Yesterday the Gnome Power tool warned me that I had 1 minute remaining. Although a 1 minute warning is useless, it at least seems to be warning me now.
8.10 with proposed updates
Dell Inspiron 8600
huiii (a00ps) wrote : | #110 |
this is very bad:
i got it too!
Sony VAIO FZ31M, ubuntu intrepid
the first time, after installation it worked automatically; gpm warned me and 1min later hibernated as set.
i was so happy, the first time it ever worked out of the box.
so i never thought about it anymore.. BUT since then it never worked again, meaning, i am trusting the gpm to do his job and suddenly, BUZZ laptop dead.
since then i tried gconf-manager, changing settings like mentioned above, but nothing works.
what works is the warning "you have one minute remaining before hibernation" and after 5min BUZZ dead.
in Hardy i helped myself by adjustin laptop-mode.conf, but those options are gone in Intrepid!
what can we do?
Endolith (endolith) wrote : | #111 |
> gpm warned me and 1min later hibernated as set.
Well this is a problem on its own. One minute is not nearly enough. Should we file a separate bug about this? Where is the 1 minute limit determined?
wow, it worked for me (still don't believe it, maybe recent updates helped)
the LCD was in "off" mode, and the Totem and Vlc were playing parallely
(well after resume I have sound problems, but that's differnent story)
(Asus laptop Z99H -- 82801G (ICH7 Family))
pruch (diogo-pruch) wrote : | #113 |
I'm using ubuntu 8.10 and I did this to solve the problem:
On Configuration Editor (gconf-editor)
I've set the followed keys:
/apps/gnome-
/apps/gnome-
/apps/gnome-
/apps/gnome-
/apps/gnome-
This means that when my battery reaches 15% GPM will show a "low battery warning", at 12% it will show a "Critical battery warning" and at 10% it will put my system to hibernate. I have a li-ion battery and use 10% to prevent damage to it.
I think that there should be a way to set these values directly on GPM, not just via gconf-editor
marco.pallotta (marco-pallotta) wrote : | #114 |
The configuration of which pruch wrote solve the problem in Hardy too.
marco.pallotta (marco-pallotta) wrote : | #115 |
I spoke to quickly. In fact, after having set the "pruch" configuration, today the system automatically went into shutdown (and this is ok) but without warning about the remaining battery charge and, moreover, it went into halt at the battery remaining level corresponding to the first warning.
huiii (a00ps) wrote : | #116 |
i solved this: i installed kde. it just works.
Henrik Nilsen Omma (henrik) wrote : | #117 |
As there is a partial work-around I'm lowering the priority from Critical to High. Also assigning it to the desktop team where it should be tracked. Ted is no longer on that team.
Could some one experiencing this please give the latest status on updated Jauntu and run 'apport-collect gnome-power-
Changed in gnome-power-manager (Ubuntu): | |
assignee: | Ted Gould (ted-gould) → Canonical Desktop Team (canonical-desktop-team) |
importance: | Critical → High |
status: | In Progress → Confirmed |
Changed in gnome-power-manager (Baltix): | |
status: | New → Invalid |
Sitsofe Wheeler (sitsofe) wrote : | #118 |
I happened to go to a near out of battery condition on my EeePC 900 with a recent Jaunty (as of a week ago) and the system correctly suspended to RAM.
Gregory Gleason (gsgleason) wrote : | #119 |
this has never worked for me. Started with 8.04 LTS then upgraded to 8.10, then installed 8.10 x86_64. Lenovo Thinkpad R61. I get the warning form gpm that my laptop will be shutdown, but it never shuts down - just dies when power is low. If any logs are required I will provide.
Clemens Wehrmann (cwehrmann) wrote : | #120 |
Thinkpad T61. This worked in gutsy and hardy, but not in intrepid and now jaunty. The fancy new status floaty warns at 4 minutes that it will hibernate in 2. 4-5 minutes later the laptop crashes... Manual hibernation works great.
Nick Steeves (nick-0) wrote : | #121 |
Thinkpad X32. Upgraded-
Which logs do I need to attach to debug this?
Thanks,
Nick
Nick Steeves (nick-0) wrote : | #122 |
Here are what seem like the relevant logs based on this document:
https:/
Please note that that my laptop *did* successfully hibernate, and return from hibernation from the "gnome-power-cmd hibernate" command.
Josh Zenker (jzenker) wrote : | #123 |
pruch's solution (https:/
My laptop does indeed hibernate (or suspend) succesfully, but last night I forgot to plug the AC power and let the laptop on. It didn't hibernate.
The problem, just in case anybody is having it, is that the time profiles are very optimistic in my machine, probably due to the fact that I haven't let the battery drain fully, ever. So, last night GPM thought that there were still time left when in fact the battery was empty.
I wasn't there (but I'm making the test right now) but I'm more or less sure that GPM issued the "low battery" warning because I swear I've seen it at some point in the past. I'm not so sure about the "critical" warning, since it should happen when only 5 minutes of battery remains. Given that the time profile was so optimistic, the laptop probably had the battery empty when GPM thought that there was half an hour left :(((
I don't know if people usually drains their batteries, but if they don't, time profiles are going to be very optimistic. Using time left for taking actions is, in that case, dangerous. Battery percentages should be much safer unless the battery lies about the percentages (which looks like it is very common...).
The solution is to tweak by hand threshold values using gconf-editor and use percentage instead of time left if profiles are way too optimistic.
I'm now carrying a test to see if time left reported by GPM has to do anything with reality in my laptop.
BTW, anybody knows where to go to know how to interpret discharge-
Scott Howard (showard314) wrote : | #125 |
@DervishD: discharge-
Could you test this with a Karmic LiveCD? Sometimes, when upgrading or changing batteries, GPM doesn't keep track of the batteries properly.
Upstream claims that this particular bug has been fixed. Could someone test a clean Karmic system (or LiveCD) to see if your computer will shut down when the battery is critical?
Changed in gnome-power-manager (Ubuntu): | |
status: | Confirmed → Incomplete |
Changed in gnome-power-manager (Ubuntu): | |
assignee: | Canonical Desktop Team (canonical-desktop-team) → Canonical Foundations Team (canonical-foundations) |
Changed in gnome-power-manager (Ubuntu): | |
assignee: | Canonical Foundations Team (canonical-foundations) → Canonical Desktop Team (canonical-desktop-team) |
Martin Pitt (pitti) wrote : | #126 |
time_critical is set to 5 minutes by default nowadays, which ought to be enough. If you can still reproduce this in current karmic, please do so, reboot, and then
tar czf /tmp/gpm-log.tar.gz /var/lib/
Attach /tmp/gpm-log.tar.gz then. Thanks!
Changed in gnome-power-manager (Ubuntu): | |
assignee: | Canonical Desktop Team (canonical-desktop-team) → Martin Pitt (pitti) |
summary: |
- [Gutsy] Action on critical battery isn't triggered - regression + Action on critical battery isn't triggered |
Changed in gnome-power-manager (Ubuntu Karmic): | |
importance: | High → Medium |
Josh Zenker (jzenker) wrote : | #127 |
I watched what happens as the battery runs down on my ThinkPad X61. Gnome-power-manager seems to accurately measure the remaining charge until it reaches about 5 percent. After that, it doesn't significantly change. Maybe whatever gpm relies on for its information isn't reporting well…?
If I set the threshold in gconf to 6 percent, hibernation occurs as advertised.
Once again, this is on Ubuntu 9.04 with gpm version 2.24.2-2ubuntu8 and the 2.6.28-13-generic kernel.
Changed in gnome-power-manager (Ubuntu Karmic): | |
status: | Incomplete → Triaged |
Aleksandr Panzin (jalexoid) wrote : | #128 |
+1 On the bug in Jaunty. No action is triggered. A notification is triggered claiming to hibernate/suspend in 1 minute, but nothing happens.
Changed in gnome-power-manager (Ubuntu Karmic): | |
milestone: | none → ubuntu-9.10 |
Changed in gnome-power-manager (Baltix): | |
status: | Invalid → Confirmed |
gidantribal (aedo999) wrote : | #129 |
same problem on Acer Aspire 6920G + Ubuntu 9.04 (kernel *.15, AMD64)
Martin Pitt (pitti) wrote : | #130 |
In Karmic we changed from hal to devicekit-power. Nobody confirmed that this bug still happens in Karmic, after the call for testing below.
I just tested it myself on my Dell Latitude D430, and I get all the "low"/"
Closing now for Karmic (hardy/jaunty are still open, since confirmed several times). Please yell if it still does not work for you in Karmic.
Changed in gnome-power-manager (Ubuntu Karmic): | |
status: | Triaged → Fix Released |
Changed in gnome-power-manager (Ubuntu Jaunty): | |
status: | New → Confirmed |
Changed in gnome-power-manager (Ubuntu Hardy): | |
status: | New → Confirmed |
live (sean-colaco) wrote : | #131 |
i have a toshiba laptop but when the battery is critical it does not go on hibernate but it just goes off without shutting down or hibernating
live [2009-10-15 18:13 -0000]:
> i have a toshiba laptop but when the battery is critical it does not go
> on hibernate but it just goes off without shutting down or hibernating
Can you please open a new bug with "ubuntu-bug gnome-power-
and do the following:
killall gnome-power-manager
gnome-
then let it drain the battery until it's down to 1% or less (it
regularly shows). Then press ^C, and attach ~/gpm.log to the bug.
Thanks!
Martin
--
Martin Pitt | http://
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Changed in gnome-power-manager (Ubuntu Karmic): | |
status: | Fix Released → Fix Committed |
status: | Fix Committed → Fix Released |
David (liradavid84) wrote : | #134 |
I still have this bug in Karmic ( on dell vostro 1310 ). I tested 8.10 and 9.10 and this dont works in both.
nameiner (nameiner) wrote : | #135 |
I have the same bug in Karmic on HP dv4-1120us.
gpm.log is attached.
Maciej Strzelecki (mstrzele) wrote : | #136 |
This bug still occurs in Karmic, even if I set use_time_for_policy to false.
Maciej Strzelecki (mstrzele) wrote : | #137 |
Bug is still appearing in current g-p-m (2.28.1-0ubuntu1) in Karmic.
Changed in gnome-power-manager (Ubuntu Karmic): | |
status: | Fix Released → Confirmed |
Martin Pitt (pitti) wrote : | #138 |
Maciej Strzelecki [2009-11-12 8:15 -0000]:
> Bug is still appearing in current g-p-m (2.28.1-0ubuntu1) in Karmic.
>
> ** Changed in: gnome-power-manager (Ubuntu Karmic)
> Status: Fix Released => Confirmed
Closing again. This bug report became fairly useless because there
were so many different issues mixed together. Can you please open a
new one with "ubuntu-bug gnome-power-
killall -9 gnome-power-manager
gnome-
then reproduce the problem, and attach /tmp/gpm.log to the new bug.
Martin
--
Martin Pitt | http://
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Changed in gnome-power-manager (Ubuntu Karmic): | |
status: | Confirmed → Fix Released |
nameiner (nameiner) wrote : | #139 |
created a new bug report: 481576
https:/
Changed in gnome-power: | |
importance: | Unknown → Medium |
JC Hulce (soaringsky) wrote : | #140 |
Thank you for taking the time to report this bug. This issue has been fixed in newer versions of Ubuntu, and Jaunty is EOL. Thus, I am closing this bugtask.
Changed in gnome-power-manager (Ubuntu Jaunty): | |
status: | Confirmed → Invalid |
Ben Gamari (bgamari) wrote : | #141 |
Has there been a new bug filed along these lines? I still seem to be running into this in Precise.
Ivan Zorin (iaz) wrote : | #142 |
To whom it may concern: bug report with similar issue - https:/
no longer affects: | gnome-power-manager (Ubuntu Hardy) |
no longer affects: | gnome-power-manager (Ubuntu Jaunty) |
Changed in gnome-power-manager (Baltix): | |
status: | Confirmed → Fix Released |
Toshiba A100-062, one battery, one frustrated user :|
Same here. It also worked fine for me in Feisty. In Gutsy this actually caused me to lose data.
It seems to work if you disable using the time for actions (somewhere in gconf). I do not see why, however, since the estimated time remaining seems quite correct.
However when it reaches ~5 minutes (also the threshold for critical battery) the time remaining is *no longer shown* in the tooltip over the red battery icon. I only see the percentage. As far as I know I am receiving no low battery warnings either (other than the tray icon changing).
This bug should be increased in priority/severity, especially since the workaround can only be accessed through gconf, and not through the UI.
If there is any data I can provide, please let me know.