Action on critical battery isn't triggered

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.

(Could be seen as related to Bug #64751 / Bug #61201 )

(Might also be related to Bug #113244 )

can you check if thats still the case with the most recent version of gnome-power-manager ?

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 ...

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.

Hurry up !!!!

You can't forget this critical bug !!

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.

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-mode/laptop-mode.conf

# Should laptop mode tools perform auto-hibernation?
ENABLE_AUTO_HIBERNATION=0
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=2
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1

I tried to set
ENABLE_AUTO_HIBERNATION=1
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=4
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1

but no luck :\

still I found sth about hibernate /etc/default/acpi-support
# Set the following to "platform" if you want to use ACPI to shut down
# your machine on hibernation
HIBERNATE_MODE=shutdown

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.

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/acpi-support to even enable the default functionality, with no mention of this in laptop-mode.conf. In the mean time, most of the *other* functionality is still broken. Especially this bit, since it depends on the laptop-mode-tools ACPI events. I might be accused of various things for suggesting this (and people will probably be right), but one could try installing the Debian version , set HIBERNATE_COMMAND=/etc/acpi/hibernate.sh and it'll probably work. The Debian package is in fact fully compatible with Ubuntu, except that it doesn't listen to what acpi-support says -- a good thing IMO.

http://samwel.tk/laptop_mode/packages/debian

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.

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

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

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-mode/laptop-mode.conf the hibernate script path is /usr/sbin/hibernate which doesnot exist in my installation.

I changed this as below and I am now waiting for my battery to drain to see if it works:

# HIBERNATE_COMMAND=/usr/sbin/hibernate
HIBERNATE_COMMAND=/etc/acpi/hibernate.sh

FYI the /etc/acpi/hibernate.sh works perfectly if you run it manually.

I will let u know of the outcome however you can try it yourselves as well.

Nicolas

Unfortunately no luck on the above; the laptop went dead as usual... :(

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.

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://bugs.launchpad.net/bugs/135548
> 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.
··························································································································································

same bug on dell xps m1330 with gutsy updated daily.

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://bugs.launchpad.net/bugs/135548
> 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-manager;gnome-power-manager --no-daemon --verbose > ~/gpm.log 2>&1
when battery has 11% of power.
as seen in:
http://en.opensuse.org/Bugs:GNOME
http://bugzilla.gnome.org/show_bug.cgi?id=506305
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.

I messed with /etc/laptop-mode/laptop-mode.conf and now I don't suffer from the bug. Basicly I did quite the same stuff as jurgis.pralgauskis (few posts above)

My config:

#
# Should laptop mode tools perform auto-hibernation?
#
ENABLE_AUTO_HIBERNATION=1

#
# The hibernation command that is to be executed when auto-hibernation
# is triggered.
#
HIBERNATE_COMMAND=/usr/sbin/hibernate

#
# Auto-hibernation battery level threshold, in percentage of the battery's
# total capacity.
#
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=2

#
# Enable this to auto-hibernate if the battery reports that its level is
# "critical".
#
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1

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...

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!

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://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nicos Christodoulou
SciCane Ltd.

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.

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

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://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

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://bugzilla.gnome.org/show_bug.cgi?id=506305 ) would help, if someone here has a gnome bugzilla account.

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@madmetal:~$ cat /proc/acpi/battery/C0FF/state
present: no
madmetal@madmetal:~$ cat /proc/acpi/battery/C100/state
present: no
madmetal@madmetal:~$ cat /proc/acpi/battery/C0FE/state
present: yes
capacity state: ok
charging state: charged
present rate: 0 mW
remaining capacity: 43000 mWh
present voltage: 16626 mV

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?

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://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

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! :)

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://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

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?

I had this error on Gutsy, and in Hardy up to alpha5, on an Acer Travelmate 2451LCi Laptop

The time_policy workaround did nothing for me.

However.
The new alpha 6 has completely solved this issue for me, I get all notifications and computer shuts down automatically.
(Joy!)

Related Bug #61201, first reported on 2006-09-18

I'm running Gutsy Gibbon on a Toshiba Satellite M50.
I found that changing ENABLE_LAPTOP_MODE from false to true in the /etc/default/acpi-support file fixed up the problem for me.

Marking as fixed. With updated HAL and GPM in Hardy I am no longer seeing this bug.

Latest updates for Hardy (alpha6), 3-4 days ago has broken this again for me, no notifications, no actions on low/crit battery.

I can also confirm that this is not working for me on the Hardy Beta, fully updated as of now.

Same for me. Hardy beta 64bit on a dell xps m1330. Not working at the moment.

For those who are still getting this bug, could you please confirm that GPM is receiving the power button event. If it is not, that is a HAL issue. If GPM is receiving it an not acting this bug should be reopened. To confirm whether GPM is getting the event please follow the instructions here:

https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#head-7d2eb767e44a7231fae6964dcf12bc27fe507c9d

I am not completely sure which of the debugging tasks you're after but here goes two (which I'm not too sure how to interpret, either)...

$ dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement'"
- Gives me no event acknowledgements at all in the terminal, neither on AC (un)plugging, nor on low battery

$ gnome-power-cmd.sh suspend
- Suspends nicely and gives output:

Suspending
Error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

If you have this problem, then try it with unchecking the following keys via gconf-editor:

/apps/gnome-power-manager/general/use_profile_time
/apps/gnome-power-manager/general/use_time_for_policy

found at: http://ubuntuforums.org/showthread.php?t=487258

Above suggestion (profile/time/policy) did nothing for me, I have tried that before on this computer [Acer TravelMate 2451LCi] when I was having the problem in Gutsy, and it didn't work then either.

You're right. It's still not working here on hardy.

@arand

Specifically I'm looking for the events that GPM is getting and the debug output from GPM. Under the title "Getting Info from GPM".

https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#head-7d2eb767e44a7231fae6964dcf12bc27fe507c9d

Oh sorry, first time I followed that link from my mail client and it didn't jump to the right header.

Anyways, I'm attaching the full gory output of gpm-debug from 100% charge to computer death.

Hope it says something.

I'm also attaching a summary of some of the "external" events which took place.

@arand

Thanks for all of the data, that helps a lot. From looking at the log
it looks like the last time that GPM gets notified of a battery level
that it's at 8 percent and that the discharge rate doesn't make it
"action level". This is likely caused by the battery being old.

What I'd recommend is adjusting your thresholds so that actions happen
sooner on your battery. The values that are probably most useful are
the GConf keys:

    /apps/gnome-power-manager/thresholds/percentage_action
 /apps/gnome-power-manager/thresholds/percentage_critical
 /apps/gnome-power-manager/thresholds/percentage_low

For you it seems like 10, 15 and 20 would probably be good values.

I'm going to mark this bug as "Incomplete" right now as asac's problem seems to be caused by hardware (old battery).

If there are other people still seeing this on Hardy (which has the upstream fix) could you please post similar logs and reopen the bug.

Thank you. Ted.

its a good idea to buy a new battery every 18 months or so.

On Fri, Apr 4, 2008 at 7:49 PM, Ted Gould <email address hidden> wrote:

> I'm going to mark this bug as "Incomplete" right now as asac's problem
> seems to be caused by hardware (old battery).
>
> If there are other people still seeing this on Hardy (which has the
> upstream fix) could you please post similar logs and reopen the bug.
>
> Thank you. Ted.
>
>
> ** Changed in: gnome-power-manager (Ubuntu)
> Status: Confirmed => Incomplete
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Alright, changing threshold percent levels AND profile/time/policy did the trick for me, so presumably the problem for me lies in the inability to use time policy

- This DID work for me somewhere on alpha6 (see former comment by me [2008-03-31]), and since I have values set to low=1200, crit=300, act=120, then before going down to 8% (time=89) and freezing it should pass all or at least the low and crit thresholds, which should give a notification.

Also, I'm getting a slightly weird output from the debug when using only percentage, it seems to drop from 19% to 6% all of a sudden.

The computer also has trouble hibernating but that I blame on the debugging, since when doing the same thing without debug it hibernates fine.

I'm attaching part of this log, if anybody's interested (which also shows failed hibernation attempts and percentage going down to 0% [which seems to upset gpm a bit])

@Chad Bernier: Holding out until I buy a new laptop.

ok wish you luck. Mine was fixed a long time ago back in this bug. I just
set it to 2% instead of time, and it works great. My sister's windows
laptop doesn't even warn you, it will just fall asleep. My hardy warns me
several times before actually hibernating.

I don't think i will be getting a new laptop for almost a year, and even
with a new one, the old one would be good for plenty of things. good luck
with whatever your plan is, hope you find a good deal.

On Fri, Apr 4, 2008 at 10:23 PM, arand <email address hidden> wrote:

> Alright, changing threshold percent levels AND profile/time/policy did
> the trick for me, so presumably the problem for me lies in the inability
> to use time policy
>
> - This DID work for me somewhere on alpha6 (see former comment by me
> [2008-03-31]), and since I have values set to low=1200, crit=300,
> act=120, then before going down to 8% (time=89) and freezing it should
> pass all or at least the low and crit thresholds, which should give a
> notification.
>
> Also, I'm getting a slightly weird output from the debug when using only
> percentage, it seems to drop from 19% to 6% all of a sudden.
>
> The computer also has trouble hibernating but that I blame on the
> debugging, since when doing the same thing without debug it hibernates
> fine.
>
> I'm attaching part of this log, if anybody's interested (which also
> shows failed hibernation attempts and percentage going down to 0% [which
> seems to upset gpm a bit])
>
> @Chad Bernier: Holding out until I buy a new laptop.
>
> ** Attachment added: "gpm.debug.log2excerpt.txt"
> http://launchpadlibrarian.net/13126675/gpm.debug.log2excerpt.txt
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

no luck again -- no ballon messages (they appeared at least in gutsy)
and no luck with all of the suggestions (log's will be attached)

hardy beta (upgraded as of 2007 04 06)
Gnome Power Manager 2.22.1

with standart config
(Asus Z99H series)

changed laptop-mode.conf

ENABLE_AUTO_HIBERNATION=1
HIBERNATE_COMMAND=/usr/sbin/hibernate
AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT=2
AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL=1

but no luck

in gpm applet Preferences changed on critical to "suspend (to ram)",
as much as I remember it worked in gutsy

no luck

via gconf-editor
gnome-power-manager -> general -> use_time_for_policy = off

the same sad ending...

@Jurgis

Could you please dump your gconf keys also:

https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#head-3064996579b2f21cb27b49abc25849d4713e64cb

Thank you. Ted.

Hi Ted,
 this is a serious regression!
I can confirm that in Gutsy worked. No matter if my battery is broken (30% capacity)...I expect that g-p-m warns me and shuts my laptop down gracefully (just like it did in gutsy).
If I can help somehow, let me know.

this is little OT, but i must admit, that "low battery" notification still appears, but quite early (todai it appeared at ~17% = 19 minutes), but I hibernated yesterday with non full battery, so the numbers might misrepresent full battery capacity)

still, where can I set the limit for "low battery" message?

Ted,

I have tested each milestone of Hardy. The RC worked for me but the final does not. My battery is fairly old. Did anything change between the RC and the final, or is it just a coincidence that things aren't working for me now?

I'm currently logging all gpm output as per:
https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#head-7d2eb767e44a7231fae6964dcf12bc27fe507c9d
and running down the battery - I'll attach this when it is complete.

Here is a side thought that may solve this problem for some: why not increase the frequency of battery polling as the level gets lower? There is probably not a huge advantage in knowing each percent point change between 90% and 80%, but it sounds as though it would make a difference under 20%.

This is the log of the battery running out when I am hardly using it (to keep the CPU at 600MHz). I still get no warnings or anything and the machine just dies.

This makes me think that something has changed since the RC. The RC gave me several warnings before Hibernating. I doubt that my battery has deteriorated that much over that time.

Everything is working now with the last version of Hardy.

nmcaramelo

On Sun, Apr 27, 2008 at 2:35 AM, Aaron Whitehouse <email address hidden>
wrote:

> Ted,
>
> I have tested each milestone of Hardy. The RC worked for me but the
> final does not. My battery is fairly old. Did anything change between
> the RC and the final, or is it just a coincidence that things aren't
> working for me now?
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

To be honest this is the last time I upgrade to a new version of ubuntu as
soon as it's released. I face a lot of problems (like I did when I switched
to 'gutsy').

The worst of all problems comes to sleep/hibernate. I was satisfied with
gutsy on this (after ofcourse spending a lot of time fixing it) and as soon
as I did the upgrade to hardy, the problems came back. Sleep and hibernate
go well but when when resuming the screen was black and while the keyboard
was not frozen there was not much to do but to just severely shut it down
and start again.

I just now after deciding to remove everything related to apm package, I
search on the repository and came up to uswsusp. After removing apm (don't
know if helped removing) and installing this package, I run the
configuration package and selected /dev/sda2 (which is my swap partition)
and voila! I tried both suspend and hibernate and work like a charm. And
guess what! it's faster on sleeping / resuming than it was when working on
gutsy.

FYI, my system is a lenovo 3000 V1000 laptop with 1.83GHz, 100Gb SATA HDD,
12" tft.

if you do a mistake on configuration of uswsusp you can re-run the
configuration with 'sudo dpkg-reconfigure uswsusp'.

regards,

Nicolas

2008/5/4 nmcaramelo <email address hidden>:

> Everything is working now with the last version of Hardy.
>
> nmcaramelo
>
> On Sun, Apr 27, 2008 at 2:35 AM, Aaron Whitehouse <<email address hidden>
> >
> wrote:
>
> > Ted,
> >
> > I have tested each milestone of Hardy. The RC worked for me but the
> > final does not. My battery is fairly old. Did anything change between
> > the RC and the final, or is it just a coincidence that things aren't
> > working for me now?
> >
> > --
> > [Gutsy] Action on critical battery isn't triggered - regression
> > https://bugs.launchpad.net/bugs/135548
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> ** Attachment added: "unnamed"
> http://launchpadlibrarian.net/14194219/unnamed
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Nicos Christodoulou
SciCane Ltd.

P.O. Box 70214
CY-4162 K. Polemidia
Limassol Cyprus
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.

The problem persist in 8.04. Thins that I've notice recently

1.- gnome-power-bugreport.sh reports (AC adapter present: yes) when the ac cable is unplugged
2.- Just few secunds before the laptop turn off the estimated remaining time graph raise up like a "charge recovered"

I tried it last week and it worked ok forme - wow, thanks! :)
probably the problem consists of several things, as manuel still experiences it

Shutting down on low battery hasn't ever worked for me in hardy.
This is the output of g-p-m while on batterie till the system turns of because the batterie is completely drained.

Everything always worked for me (after some charge/discharge cycles enough to create a battery profile...) but, after i've enabled laptop-mode-tools something changed: I get some notifications about my battery discharge but, after I get the critical warning notification the system simply doesn't hibernate and when the battery is empty the system powers off :-(

I tried several solutions but now I'm starting to think that something goes weird when one has laptop-mode-tools running together with g-p-m...

Should I tell laptop-mode-tools to manage the critical battery level event?
And, if I enable the above in laptop-mode-tools, will the "hibernate when lid closed" event work?
Robbie

Things seem to fluctuate for me in Hardy. As far as I can tell, it
sometimes works and sometimes doesn't. I would love to have somebody
help us isolate the problem.

The other day I tried a debug as often suggested here and I found that g-p-m was configured to trigger the "critical action" when 2 minutes was left but g-p-m keeps on showing 5 minutes even when acpi tells that the battery percentage is 0%
So I adjusted the thresholds to fit what I think is correct for my battery/laptop and now, when I have less than 5 minutes remaining my machine gets hibernated.

2008/5/26 Roberto Scelzo <email address hidden>:
> The other day I tried a debug as often suggested here and I found that g-p-m was configured to trigger the "critical action" when 2 minutes was left but g-p-m keeps on showing 5 minutes even when acpi tells that the battery percentage is 0%
> So I adjusted the thresholds to fit what I think is correct for my battery/laptop and now, when I have less than 5 minutes remaining my machine gets hibernated.
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hello List,

  I did increase the threshold and now the machine take the action
before the critical and insuperable time. Unfortunately my Acer is not
hibernating any more in 8.04 but this is another thread. I did setup
to shutdown and it works.

Later,
Manuel Soto

This works for me now on Gutsy with all updates. I have use_profile_time and use_time_for_policy both enabled (default).
I also raised the time thresholds (low, critical, action) to 1560, 960 and 660.

For me, the solution was to go through a couple of charge/discharge cycles without letting it drain through. This helped it to build up a profile of my battery. I think this point should be mentioned somewhere in g-p-m so that the user knows that it doesn't work well until a profile is built up. Alternatively, the system should use a higher threshold value by default (err on the safe side) until a profile is built up.

For me, it also does not trip at 10%. It might be because it is monitoring the time until it reaches the trip point. Highlighting the battery shows about 20-20 minutes less time than the battery actually has, according to the output from acpi.

Sorry, 20-30 minutes less time

As far as I could tell from the code, Anoop P B has the correct solution (which I can see from the output of my g-p-m).

If the battery profile of the (primary) battery isn't good enough (accuracy less than 40%), no action will be taken, and no warnings will be shown. This is true even if use_time_for_policy is disabled, which is just plain stupid. It's also quite unacceptable for most cases, since it can cause both data loss and file system corruption if the user doesn't shut down manually in time.

I'm going to make an attempt to fix this later tonight (I'm at work right now) by adding two things:
1. A check that takes actions even with a "bad" profile when use_time_for_policy is disabled.
2. A fallback that will use the percentage instead of time if the profile isn't good enough yet.
If I'm successful, of course I will submit my patch.

I think this bug is actually quite critical since it only affects new users. (New users of gnome, that is. I recently switched from KDE.)

As I said in my last comment, I would submit my patch when I was done with it, and here it is.

Cited from the changelog of my patched package:
   * Added 11_policy_actions_fallback.patch which makes policy actions
     fall back to per-percent policy if the battery profile is not good
     enough yet. It also ignores the accuracy of the battery profile when
     the GCONF key 'use_time_for_policy' is disabled. LP: #135548
   * Added 12_fix_critical_message.patch which fixes an error in the
     notification messages for critical battery. These messages would
     always show 0% battery remaining, since the cell unit object was
     reset while generating one of the strings used in the message.

(yup, the second point means I found another bug as well)

I'm attaching the .diff.gz file generated by dpkg-build package, since that is the simplest way for me to attach all my changes in one file.

A small disclaimer: I'm no C guru, and this was actually the first thing I did with GTK based code. That means my solutions may not be "correct", but they work for me, as far as I could tell.

I'm running Hardy, upgraded via package manager, with all updates applied, and my computer wasn't hibernating (or notifying) on critical power. I unchecked the "use time" box in gconf, and it's working fine.

Just FYI - it was an issue on my Hardy install.

I would also note that my "time" indication never dropped below 10 minutes (I have a battery that lasts ~4.5 hours), which may explain the lack of warning or action with the time settings.

2008/6/27 5of0 <<email address hidden><cincodenada%<email address hidden>>
>:

> I'm running Hardy, upgraded via package manager, with all updates
> applied, and my computer wasn't hibernating (or notifying) on critical
> power. I unchecked the "use time" box in gconf, and it's working fine.
>
> Just FYI - it was an issue on my Hardy install.
>
> --
> [Gutsy] Action on critical battery isn't triggered - regression
> https://bugs.launchpad.net/bugs/135548
> You received this bug notification because you are a direct subscriber
> of the bug.
>

As far as I understand Power Manager learn so you have to learn how the
battery works. My Laptop is working now.

This problem exist in Ubuntu and Lenny and was solved in both letting power
manager to learn. Plug the power cord or manually hibernate for a while.

Later,
Manuel Soto

Upstream bug report says it's solved. Why is the solution not patched in Ubuntu?

BTW, the workaround in comment 18 works for me, on a Lenovo 3000 v100 (Ubuntu 8.04).

I have the same problem on a HP Compaq 8510p. I found it strange that the default settings were to "Do nothing" when battery power is critically low, so I changed it to "Hibernate".

Unfortunately this does not work, it just keeps going until the battery is drained.

I'm running the latest Ubuntu 8.04 x86_64 with kernel 2.6.24-19-generic.

Any ideas on how to solve this? Is this a known issue?

By the way, I also set the action to "Suspend" when the laptop lid is closed. This does not work either.

Forgot to mention it, but the gnome-power-cmd.sh suspend commands do work (both for suspend and hibernate).

Jo Vermeulen: Have you tried unchecking "use time" in gconf-editor, as mentioned above (https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/135548/comments/19)?

5of0,

My bet is that "use time" doesn't help, because gnome-power-manager is coded to work just like this (I've read the code).

Like I've said in a previous comment (https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/135548/comments/88), gnome-power-manager WILL NOT DO ANYTHING until it has a reliable battery profile (which occurs after 5-10 battery full cycles while g-p-m is running). This is also true even when "use_time_for_policy" is unchecked, which is just plain stupid since the battery percent can be gotten through normal ACPI information and doesn't need any profile.

As I've also mentioned above (https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/135548/comments/89), I HAVE MADE A WORKING PATCH for this (I've run it myself for a while without any problems at all). I fail to see why NOBODY seems to have noticed that.

Done, will see what it does when the battery runs out again. Is this caused
by a broken ACPI as suggested by gconf-editor, or a bug in Gnome Power
Manager? Should I reset this value once the bug gets fixed?

-- Jo

@joakim, so in fact I can just wait for a few days and then it should work again? So it's then probably also better to check use_time_for_policy again.

Or do I need your patch to get this working?

If this is true, then probably this is not a bug after all (and it should be marked as such).

Jo,

Well make it a week or two. Running the computer with the electrical cord in place does not count (although it does add data about how the battery charges). You can check the progress by right clicking g-p-m in the system tray, selecting "power history" and then in that box (near the bottom), select "discharge time accuracy profile". when the average value of that graph is over 40%, stuff will start working.

What my patch does it fix the gap before it starts working. First and foremost, caring about the profile even when use_time_for_policy is disabled is just weird, since the profile doesn't add anything to the mix at that point. Then, not telling the user anything about this thing with ignoring actions is just a bad idea, there's no warning anywhere. I actually "fell into the trap" myself a few days ago, after installing ubuntu on my new laptop. Thank god no data was lost, because I was in the middle of doing quite a lot.

I still think this is a bug, since a developer put in this accuracy check for a good cause (some broken ACPI's could make the computer hibernate way too early, according to the changelog), but probably didn't think about what would happen until the accuracy profile was good enough.

And yes, you can enable use_time_for_policy again.

Joakim, thank you very much for the detailed reply.

I also found out suspend after closing the lid does work after all (I just didn't wait long enough).

I hope your patch (or maybe a more polished version) will get integrated in the next release. Do you have a package for this, or is there an easy way to apply it (sorry, I'm a dpkg rookie)? Otherwise I'll just wait for a while, I can live with it if will work eventually.

But you are right, it is really bad for new Ubuntu or Gnome users, so it should be resolved as soon as possible. In my opinion the fix should even be pushed as an update in the official Hardy Ubuntu repositories.

This bug was fixed in the package gnome-power-manager - 2.23.91-0ubuntu2

---------------
gnome-power-manager (2.23.91-0ubuntu2) intrepid; urgency=low

  * Added two patches from Joakim Andersson <email address hidden> his
    comments on the patches are below.
  * Added 18_policy_actions_fallback.patch which makes policy actions
    fall back to per-percent policy if the battery profile is not good
    enough yet. It also ignores the accuracy of the battery profile when
    the GCONF key 'use_time_for_policy' is disabled. LP: #135548
  * Added 19_fix_critical_message.patch which fixes an error in the
    notification messages for critical battery. These messages would
    always show 0% battery remaining, since the cell unit object was
    reset while generating one of the strings used in the message.

  * 18_policy_actions_fallback.patch: Modified by Richard Hughes to
    make cleaner and smaller. Now keeps most prototypes intact.
  * I updated 18_policy_actions_fallback.patch from Richard's version
    to make it apply cleanly on 2.23.91.

gnome-power-manager (2.23.91-0ubuntu1) intrepid; urgency=low

  * Upstream release:
    * Handle "unknown" battery technology in HAL
    * Bug fixes (LP: #260314)
  * 75-ignore-long-failed-suspends.patch: added to prevent inaccurately
    indicating failed suspends when they were >= 6 hours. (LP: #242713)
    From Mario Limonciello <email address hidden>
  * 14_inhibit_tool.patch: A small tool to allow command line apps to
    use the inhibit DBus interface easily.
  * 17_icon_cache.patch: A patch to build the icon cache in the correct
    directory.
  * 50-r2882-fix-547766.patch: Removed as merged upstream.

 -- Ted Gould <email address hidden> Wed, 10 Sep 2008 09:36:40 -0500

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/battery/BAT0/state my Thinkpad T43 battery discharges very regulary (10-40 mWh / sec steps) until it reaches the alarm-capacity of 2206mWh (/proc/acpi/battery/BAT0/alarm) - from no on the state doesn't change anymore for some time and remains at about 1800 mWh. This represents about 4% remaining capacity (shown by left-click on g-p-m applet).

- 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.

Addendum: things seem to be more complicated.

Using "use_time_for_prolicy" I cannot manage to make my system shutdown automatically, even with 360-seconds as power-off treshold. This should work, as when my laptop battery reaches 3% the calculated remaining time drops to 5-minutes (300sec < 360), but nothing happens.

Disabling "use_time_for_prolicy" and raising up corresponding theshold seems to work better.

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.

Tested in Ubuntu Intrepid - not working!

also still problem on Intrepid with Asus Z99H

Same problem on a NEC P550. I hope changing the GConf-value helps.

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.

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

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?

> 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))

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-power-manager/general/use_time_for_policy (false)
/apps/gnome-power-manager/thresholds/percentage_low (15)
/apps/gnome-power-manager/thresholds/percentage_critical (12)
/apps/gnome-power-manager/thresholds/percentage_action (10)
/apps/gnome-power-manager/actions/critical_battery (hibernate)

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

The configuration of which pruch wrote solve the problem in Hardy too.

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.

i solved this: i installed kde. it just works.

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-manager' to gather the latest attachments? Thanks!

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.

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.

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.

Thinkpad X32. Upgraded-from-Intrepid-to-Jaunty. Gnome Power Manager correctly detects the battery state, correctly issues a "low battery warning" but doesn't initiate hibernation until 0% battery is reached. Additionally, the normal battery light starts flashing orange at the appropriate time...but still no automatic hibernation. What happened? This used to be one of the most reliable and supported laptops *ever*! Manual hibernation and resume still work great.

Which logs do I need to attach to debug this?

Thanks,
Nick

Here are what seem like the relevant logs based on this document:
https://wiki.ubuntu.com/DebuggingGNOMEPowerManager#head-7d2eb767e44a7231fae6964dcf12bc27fe507c9d

Please note that that my laptop *did* successfully hibernate, and return from hibernation from the "gnome-power-cmd hibernate" command.

pruch's solution (https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/135548/comments/113) worked perfectly for me in Ubuntu 8.04 (2.6.24-24-generic) on a ThinkPad X61. However, I do think this is a bug that needs to be addressed, since the average user won't know to use gconf-editor or read through bug reports to fix it.

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-time-profiles? I don't understand mine and maybe it explains the wrong behaviour of GPM in my laptop :?

@DervishD: discharge-time-profile tells you the amount of time your laptop spends with a specific battery percentage during a single discharge. For example, in your image, your laptop would quickly discharge from 100 to 90 percent, then slow down from 90-10, then quickly accelerate from 10-0.

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?

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/DeviceKit-power

Attach /tmp/gpm-log.tar.gz then. Thanks!

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.

+1 On the bug in Jaunty. No action is triggered. A notification is triggered claiming to hibernate/suspend in 1 minute, but nothing happens.

same problem on Acer Aspire 6920G + Ubuntu 9.04 (kernel *.15, AMD64)

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"/"critical"/"suspending now" notifications, and the computer suspends when the battery reaches 1.5% charge (it falls back to percentage because it can't estimate the remaining time below 5% any more). I believe g-p-m's policy is correct now. Remaining problems could be that the battery remaining time/percentage is misdetected. This is a hardware specific problem then, and should be reporteded individually against devicekit-power.

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.

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-manager"
and do the following:

  killall gnome-power-manager
  gnome-power-manager --verbose 2>&1 | tee ~/gpm.log

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://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

I still have this bug in Karmic ( on dell vostro 1310 ). I tested 8.10 and 9.10 and this dont works in both.

I have the same bug in Karmic on HP dv4-1120us.

gpm.log is attached.

This bug still occurs in Karmic, even if I set use_time_for_policy to false.

Bug is still appearing in current g-p-m (2.28.1-0ubuntu1) in Karmic.

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-manager" and attach the log?

  killall -9 gnome-power-manager
  gnome-power-manager --no-daemon --verbose >/tmp/gpm.log 2>&1

then reproduce the problem, and attach /tmp/gpm.log to the new bug.

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

created a new bug report: 481576
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/481576

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.

Has there been a new bug filed along these lines? I still seem to be running into this in Precise.

To whom it may concern: bug report with similar issue - https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/1096912 - but on 12.10