Pulling AC plug suspends computer

[DanH]

g-p-m (I guess) immediately suspends when switching from AC to battery - even if the battery is full (as reported by g-p-m itself after unsuspension).

This is almost always reproducible.

[Richard Hughes (richard-hughes)]

What version g-p-m? Do you know why it suspends? What does the verbose log print when it suspends? Thanks.

[DanH (holmsand-gmail)]

2.13.91-0ubuntu3

It turns out that this only happens after a "suspend via lid close" has happened at least once - this seems to mess up g-p-m's internal state somehow.

Below is the result of running "gnome-power-manager --no-daemon --verbose", and (1) closing and opening lid, and (2) Pulling AC plug (which triggers the suspension) and un-resuming via power button.

And I have no idea why it suspends...

Log output follow:

[watch_device_condition] gpm-hal-monitor.c:296 (22:53:14): udi=/org/freedesktop/Hal/devices/acpi_LID, name=ButtonPressed, details=lid
[watch_device_condition] gpm-hal-monitor.c:319 (22:53:14): ButtonPressed : lid
[watch_device_condition] gpm-hal-monitor.c:344 (22:53:14): emitting button-pressed : lid, lid (1)
[hal_button_pressed_cb] gpm-power.c:1029 (22:53:14): emitting button-pressed : lid, lid (1)
[power_button_pressed_cb] gpm-manager.c:972 (22:53:14): Received a button press event type=lid details=lid state=1
[lid_button_pressed] gpm-manager.c:920 (22:53:14): button changed: 1
[lid_button_pressed] gpm-manager.c:929 (22:53:14): Performing AC policy
[manager_policy_do] gpm-manager.c:575 (22:53:14): policy: /apps/gnome-power-manager/action_ac_button_lid
[manager_policy_do] gpm-manager.c:596 (22:53:14): *ACTION* Suspend
[manager_do_we_screensave] gpm-manager.c:511 (22:53:14): Using ScreenSaver settings (1)
[gpm_screensaver_lock] gpm-screensaver.c:159 (22:53:14): lock
*** WARNING ***
[gpm_hal_suspend] gpm-hal.c:202 (22:53:38): An unknown error occured
*** WARNING ***
*** WARNING ***
[gpm_hal_suspend] gpm-hal.c:205 (22:53:38): org.freedesktop.Hal.Device.SystemPowerManagement.Suspend failed (HAL error)
*** WARNING ***
[gpm_tray_icon_notify] gpm-tray-icon.c:760 (22:53:38): doing notify: Suspend Problem
[get_widget_position] gpm-tray-icon.c:589 (22:53:38): widget position x=1023, y=767
*** WARNING ***
[libnotify_event] gpm-tray-icon.c:631 (22:53:38): libnotify: Power Manager : Your computer failed to suspend.
Check the <a href="http://www.gnome.org/projects/gnome-power-manager/faq.html">FAQ page</a> for common problems.
*** WARNING ***
[gpm_screensaver_poke] gpm-screensaver.c:188 (22:53:38): poke
[session_idle_changed_handler] gpm-idle.c:353 (22:53:38): Received GS idle changed: 1
[add_system_timer] gpm-idle.c:187 (22:53:38): System idle disabled
[gpm_idle_set_mode] gpm-idle.c:202 (22:53:38): Doing a state transition: 1
[idle_changed_cb] gpm-manager.c:833 (22:53:38): Idle state changed: SESSION
[gpm_dpms_set_active] gpm-dpms-x11.c:457 (22:53:38): setting DPMS active: 1
[x11_sync_server_dpms_settings] gpm-dpms-x11.c:117 (22:53:38): Syncing DPMS settings enabled=1 timeouts=1800 1800 3600
[x11_sync_server_dpms_settings] gpm-dpms-x11.c:193 (22:53:38): set DPMS timeouts: 1800 1800 3600.
[x11_sync_server_dpms_settings] gpm-dpms-x11.c:117 (22:53:38): Syncing DPMS settings enabled=1 timeouts=1800 1800 3600
[hal_device_removed] gpm-hal-monitor.c:525 (22:53:38): udi=/org/freedesktop/Hal/devices/net_00_0b_5d_53_5e_dc
*** WARNING ***
[watch_device_disconnect_condition] gpm-hal-monitor.c:404 (22:53:38): Device is not b...

[Richard Hughes (richard-hughes)]

Thanks for the log:

[power_on_ac_changed_cb] gpm-manager.c:1036 (22:53:59): Doing battery policy when lid closed and power removed
[manager_policy_do] gpm-manager.c:575 (22:53:59): policy: /apps/gnome-power-manager/action_battery_button_lid
[manager_policy_do] gpm-manager.c:596 (22:53:59): *ACTION* Suspend

Your laptops thinks you have the lid shut when you remove the ac_adapter, and does the on_battery lid action, which in your case is shutdown.

I've searched in the CVS version fo "Skipping suppressed button event" and it found nothing. After WASTING 40 MINUTES trying to find the bug in gnome-power-manager, I found the code in http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-power-manager/gnome-power-manager_2.13.91-0ubuntu3.diff.gz -- which means it's an ubuntu specific feature with a bug, rather than an upstream bug.
IF THIS NEW FUNCTIONALITY WAS OFFERED UPSTREAM I COULD HAVE SPOTTED THE BUG before it was committed and have the new code for all to use.
I am seriously thinking of not answering any ubuntu-specific bugreports if "new" functionality was not even "suggested" on a gnome bugzilla. I feel ripped off, and have wasted nearly an hour of my FREE TIME. I'm not paid to hack g-p-m.
Sorry for all the capitals, but I feel very emotional about this.

Richard.
Upstream Author
Not an Ubuntu User

[Daniel Silverstone (dsilvers)]

Yes, this looks like an ubuntu specific bug. Richard, to be fair, this is a bug filed against the ubuntu package and as such you should expect there to be differences. I have been working on integrating 2.13.92 and I will try to ensure that all messages I add in the ubuntu package are marked with "UBUNTU DEBUG" or something.

I hadn't forwarded these suggestions upstream because we weren't sure they were right yet, indeed this bug indicates that at least one bit of our patches was wrong at least in part.

Please don't feel cheated or angry at us for trying to solve our users' specific use-cases before punting code upstream. If I sent you bugs for everything I tried, you'd be inundated.

[DanH (holmsand-gmail)]

Richard,

thanks for the kind words.

I can assure you that I've wasted more than an hour trying to get the g-p-m/gnome-screensaver combo to work.

And I can assure you that I wont be filing any more bugs against them. Plain xscreensaver/acpi-support may not be as buzzword compliant, but they work. All the time.

Thank you for validating my choice.

[Richard Hughes (richard-hughes)]

>Please don't feel cheated or angry at us for trying to solve our users'
>specific use-cases before punting code upstream.

Daniel, half the patches in the ubuntu mega-patch are obvious fixes (like fixes for segfaults, or adding obvious functionality like the hibernate key) that I could have pushed upstream in about 25 seconds.

DanH, aplologies if this seemed like it was directed at you, it really wasn't. You provided me a great debug trace that would have otherwise solved the problem.

Richard.

[Daniel Silverstone (dsilvers)]

DanH: Can you please confirm if this is fixed in 2.13.92-0ubuntu1 ?

[Paul Sladen (sladen)]

Richard: does this stuff still need pushing upstream from the patch linked above. I can try to split it out if that's useful and you haven't already cherry-picked it.

[DanH (holmsand-gmail)]

Yes, Daniel. No suspend on AC-pulling with 2.13.92-0ubuntu1. Thanks!

However, gnome-power-manager isn't started automagically on login anymore, and doesn't change icon when I pull/reinsert AC.

[Richard Hughes (richard-hughes)]

Daniel, which patch linked? Thanks.

[Daniel Silverstone (dsilvers)]

Fixed in 2.13.93-0ubuntu1

[Reinhard Tartler (siretart)]

When upgrading to 2.13.93-0ubuntu1, this was fixed for me. Since some days, this bug reappeared. I have package version
2.13.93-0ubuntu3 installed.

[Reinhard Tartler (siretart)]

Additional Info: This bug occurs if the laptop has been running on battery with critically low battery state. Please try these steps to reproduce:

1. run on battery
2. wait for charge level to fall really low, so that you get a notification from gnome-power-manager that you have critically low power.
3. charge it again.

now if you pull the ac plug, you should see this bug.

[Daniel Silverstone (dsilvers)]

I attempted this yesterday and didn't get anywhere. Also you claim it worked in 2.13.93-0ubuntu1 but not in 2.13.93-0ubuntu3 which seems odd because the changes between there shouldn't have affected this bug at all (just packaging changes)

I am currently preparing a 2.14.0+CVS version of the package, we should try again once that's uploaded.

[Teguh (teguh-redhat-bugs)]

Description of problem:
When i unplugged the AC adapter, my laptop goes to hibernate (my battere is full)

Version-Release number of selected component (if applicable):
gnome-power-manager-2.14.0-1

How reproducible:
always

Steps to Reproduce:
1. Open gnome-power-manager preference
2. Click on 'Running on AC' tab
3. Change 'actions when laptop lid is closed' to 'hibernate'
4. Unplug the AC adapter

Actual results:
system is hibernate

Expected results:
keep running

Additional info:
my system:
ibm g40

[Richard (richard-redhat-bugs)]

As root, can you do:

cat /var/log/messages | grep gnome

and reply with the output here.

Thanks.

[Teguh (teguh-redhat-bugs)]

Here the output ..

Mar 31 11:02:25 gazebo gnome-power-manager: Hibernating computer because the lid
has been closed, and the ac adapter removed

I'm not close the lid (just unplugged the ac adaptor), don't know why the
messages say the lid is closed

[Daniel Holbach (dholbach)]

This bug happens to me too, and it doesn't have to be critical power, it just happened with 82% of battery left. It's not 100% reproducible, but I'll keep trying to get a verbose log.

[Richard (richard-redhat-bugs)]

Can you grab me a g-p-m verbose trace when this happens please. Thanks.

[David (david-redhat-bugs)]

Created attachment 127129
gpm verbose trace

[Richard (richard-redhat-bugs)]

*** Bug 187512 has been marked as a duplicate of this bug. ***

[Richard (richard-redhat-bugs)]

Okay, that was exactly what I was expecting. Can you please try to reproduce the
problem again, but this time run "lshal -m" as the computer (wrongly) suspends.

Thanks.

[Richard (richard-redhat-bugs)]

Also, I need the complete gpm verbose trace, including the initialisation stuff.
Thanks.

[Daniel (daniel-redhat-bugs)]

Start monitoring devicelist:
-------------------------------------------------
acpi_AC property ac_adapter.present = false
acpi_BAT0 property battery.charge_level.percentage = 94 (0x5e)
acpi_BAT0 property battery.remaining_time = 13464 (0x3498) (new)
acpi_BAT0 property battery.charge_level.rate = 18925500 (0x120c7bc)
acpi_BAT0 property battery.charge_level.current = 70784700 (0x43816bc)
acpi_BAT0 property battery.voltage.current = 12265 (0x2fe9)
acpi_BAT0 property battery.reporting.rate = 1705 (0x6a9)
acpi_BAT0 property battery.reporting.current = 6377 (0x18e9)
acpi_BAT0 property battery.rechargeable.is_discharging = true
acpi_AC property ac_adapter.present = true
acpi_BAT0 property battery.charge_level.percentage = 100 (0x64)
acpi_BAT0 property battery.remaining_time removed
acpi_BAT0 property battery.charge_level.rate = 0 (0x0)
acpi_BAT0 property battery.charge_level.current = 75013800 (0x4789ea8)
acpi_BAT0 property battery.voltage.current = 12417 (0x3081)
acpi_BAT0 property battery.reporting.rate = 1 (0x1)
acpi_BAT0 property battery.reporting.current = 7200 (0x1c20)
acpi_BAT0 property battery.rechargeable.is_discharging = false

[David (david-redhat-bugs)]

Created attachment 127140
full gpm verbose output

[Richard Ferguson (ufergus)]

I would like to add that I just experienced this bug as of 3-31-06 with all the latest updates. Haven't been able to reproduce yet, but I am trying. I was running on battery for a while, and the charge dropped pretty low before I plugged the AC back in. I'll post more if I can get the process repeatable.

[Richard (richard-redhat-bugs)]

Can you explain *exactly* what you did (in minutae detail please) to get the
debug trace -- I see you opened and closed the lid a few times.
Also, can you try the patch in :

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183709#c18

You don't have to recompile anything.

Thanks.

[David (david-redhat-bugs)]

I'm sorry, I forgot to mention I had already applied the patch when I generated
the gpm output. Unfortunately it did not change the behavior.

The edited log I first posted shows the "removing the AC power" events, leading
to the unexpected hibernate.

Here is an explanation of the full log:
Start gpm on a freshly booted system. On my first attempt at getting the system
in a confused state, I hit the lid button with my finger, leaving the lid open.
Hibernate, then resume. Remove power cord. Things still seem to be working fine.
So it seems closing the lid, and reopening it after hibernating is important.
Plug power cord back in.
Close lid, hibernate. Open lid, then resume. Remove power cord, and unexpected
hibernate happens.

Another point: if the system is in a confused state, and I do "service haldaemon
restart" (which causes gpm to crash), and then restart gpm, things work normally.

Should also mention, that if I do not use gpm, but hibernate via acpi scripts
that call pm-hibernate, hal gets into the same confused state.
When the lid is open, I get:

lshal -l | grep button.state
  button.state.value = false (bool)

When the lid is open, and hal is confused I get:
 lshal -l | grep button.state
  button.state.value = true (bool)

Restarting hal sets this to false.

So one question is: should pm-hibernate be returning hal to a pristine state (in
which case the bug is in pm-utils), or should pm-hibernate only be called via
the hal scripts?

[Daniel Holbach (dholbach)]

It's really funny, if I don't observe it with --no-daemon --verbose, I can't reproduce it at all (not with specific amounts of battery left, not with "first unplug", no combination works). :-/

[Zack Cerza (zcerza-deactivatedaccount)]

I thought this was fixed, but I just ran into it again. 2.14.0-1.

[Rod (rod-redhat-bugs)]

I am seeing similar issue to this. My problem manifests itself most often with
this situation:

1. Using system with power adapter.
2. Close lid (suspend) *then* remove power adapter
3. No adapter, open lid

At this point the system comes back from suspend, and about 10 seconds later it
suspends. Just enough time to type in a password or plug in a usb cable. At
first I thought that I was doing something wrong but I can open the lid and step
back, and it will re-suspend without any intervention.

AFAIKS it appears that button.state.value gets stuck at true (it is true right
now) - maybe when the system detects the power adapter removal (after resume on
lid open) it also sees the erroneous button state, which causes it to suspend.

Here are the relevant log items:

Close lid on AC:
Apr 6 16:41:40 localhost gnome-power-manager: Suspending computer because the
lid has been closed on ac power
Disconnect AC and open lid, then:

Apr 6 16:42:22 localhost gnome-power-manager: Suspending computer because the
lid has been closed, and the ac adapter removed

[Sébastien MURER (MuMu) (seb-murer)]

I just faced the same problem : when pulling AC plug, notification tells me I only have 2 minutes left (while battery is fully charged :/). The only way I found to get rid of it is changing the behaviour of the system when battery goes critical : do nothing stead of suspending ! :-)

[Lowe-brown (lowe-brown)]

After a fresh hald start, acpi and hal agree on the lid state of my laptop

[root@trillian lowe]# lshal -l | grep button.state
  button.state.value = false (bool)
[root@trillian lowe]# cat /proc/acpi/button/lid/LID/state
state: open

However, after hibernating (by closing the lid) and resuming, they disagree
[root@trillian lowe]# lshal -l | grep button.state
  button.state.value = true (bool)
[root@trillian lowe]# cat /proc/acpi/button/lid/LID/state
state: open

I am using hal version 0.5.7 plus the patch for hal-system-power-hibernate that
rescans the button on resume. So rescanning isn't setting the correct state.

Restarting hald on resume returns the values to normal.

This is related to gnome-power-manager bug
http://bugzilla.gnome.org/show_bug.cgi?id=334220

[Koichi (koichi-redhat-bugs)]

It seems there are more then one issues here, but
changing line 1220 of gpm-manager.c from

        if (! on_ac && manager->priv->lid_is_closed) {
to
        if ( (! on_ac) && manager->priv->lid_is_closed) {

worked for the problem I experienced (unplugging ac
suspended my laptop).

Koichi

> Description of problem:
> When i unplugged the AC adapter, my laptop goes to hibernate (my battere is full)
>
> Version-Release number of selected component (if applicable):
> gnome-power-manager-2.14.0-1
>
> How reproducible:
> always
>
> Steps to Reproduce:
> 1. Open gnome-power-manager preference
> 2. Click on 'Running on AC' tab
> 3. Change 'actions when laptop lid is closed' to 'hibernate'
> 4. Unplug the AC adapter
>
> Actual results:
> system is hibernate
>
> Expected results:
> keep running
>
> Additional info:
> my system:
> ibm g40

[Zack Cerza (zcerza-deactivatedaccount)]

Here's the verbose log from g-p-m when I unplugged my AC adapter just now. I believe my battery was 98% charged. I'm using 2.14.0-1.

[Zack Cerza (zcerza-deactivatedaccount)]

OK, it happened again at a 71% charge. The key might be this:

[gpm_syslog] gpm-debug.c:117 (14:40:34): Saving to syslog: Suspending computer because the lid has been closed, and the ac adapter removed

The lid was definitely not closed. :)

[Thomas M Steenholdt (tmus)]

I'm seing the exact same thing on my system and I know of a few other systems
that are hit by this bug as well (i don't know of any system that's not).

3rd party tools, like gnome-power-manager, that relies on this information from
hal can't help making bad decicions. So, whenever i unplug AC from my laptop to
move to another desk, my system is suspended because it thinks the lid is shut.

[Zack Cerza (zcerza-deactivatedaccount)]

It's happening a lot today. Here are log snippets from the involved parties. Note that lshal -m doesn't mention a lid button event.

[Daniel Holbach (dholbach)]

I have the panel icon set to display "only when critical". After charging it for the whole day, I pulled the plug to take the laptop to another room. It was charged 100% and while g-p-m decided to suspend the machine, it showed the g-p-m icon. It clearly seems to assume my battery power to be in a critical state.

[Richard Hughes (richard-hughes)]

Daniel, it might be that ACPI momentarily told hal that it had 0% charge. What does "cat /var/log/messages | grep gnome" have as the reason?

[Daniel Holbach (dholbach)]

Richard, the output is empty.

[Richard (richard-redhat-bugs)]

I've fixed the hal side of the problem:

See the first entry here: http://live.gnome.org/GnomePowerManager/Faq

Koichi, I think you may hae found *another* bug, but I'll look in more detail later.

[Richard Hughes (richard-hughes)]

I've fixed the hal side of the problem:

See the first entry here: http://live.gnome.org/GnomePowerManager/Faq

[Bastien (bastien-redhat-bugs)]

Created attachment 128162
gnome-power-manager-2.14.1-dont-suspend-on-ac-unplug.patch

Patch version

[Bastien (bastien-redhat-bugs)]

That patch, along with Richard's in comment #14 fixes the problem for me.

[Bastien (bastien-redhat-bugs)]

i386 RPMs:
http://files.hadess.net/redhat/rawhide/i386/
and sources:
http://files.hadess.net/redhat/rawhide/source/

[Richard (richard-redhat-bugs)]

Committed to 2-14 and HEAD:

2006-04-24 Richard Hughes <email address hidden>
 * src/gpm-manager.c (power_on_ac_changed_cb): Fix an operator precedence
problem where the logic was all messed up. This was triggering the not-on-ac
lid-closed behavior and causing seemingly random suspends. Big thanks to Koichi
Takahashi for spotting the problem.

I'll release 2.14.2 sometime soon and we can push this to updates as a priority.

Thanks for the help, Koichi and Bastien, this was a difficult bug to crack.

Richard.

[Thomas (thomas-redhat-bugs)]

Afraid to say this doesn't do the trick for me.

I have the hal scripts patched (and hal seems to provide the correct lid state
now). But with g-p-m 2.14.2, my system still suspends when my AC cable is
unplugged...

I'll attach lshal -m and g-p-m verbose log for:

fresh start
unplug ac (no issues)
replug ac
close lid (suspend)
open lid (resume)
unplug ac (suspend)
wakeup
replug ac

Hope I'm not missing anything special here...

[Thomas (thomas-redhat-bugs)]

Created attachment 128169
output of lshal -m for the duration of the test

[Thomas (thomas-redhat-bugs)]

Created attachment 128170
gpm 2.14.2 verbose log for the duration of the test

[Richard (richard-redhat-bugs)]

Thomas, you are correct. Although the lid value is now correct in HAL, because
there is no ButtonPressed event, we ignore it.

Not cool.

I'll think of the best way to solve this today.

Richard.

[Richard (richard-redhat-bugs)]

Created attachment 128189
fix that works for me

Thomas, can you try the attached patch agains CVS head pls. It seems to work
for me.

[Richard (richard-redhat-bugs)]

Created attachment 128190
same patch against 2-14

This is the same patch against 2-14 if CVS scares you.

[David (david-redhat-bugs)]

the patch from #24 finally does the trick for me

[Richard (richard-redhat-bugs)]

Thanks for testing that David, if they work for Thomas also, I'll commit both to
the respective branches.

[Thomas (thomas-redhat-bugs)]

Heh... I'm not afraid of CVS, but since you provided the patch againsg 2.14, it
was slightly more convenient to test that one out :)

And it seems to work. My thinkpad stays awake on removal of AC power even after
the LID has been closed/re-opened once. So this is great news!

One thing i noticed, that I'm not at all certain is related or even a bug, was
that immediately after resume from suspend to memory, if i unplug the AC
adapter, i get no notification "bubbles". Like i said, i'm not sure what may be
causing this or if it's even a problem - i just thought i'd mention it, now that
i noticed.

From my pov, this bug can be closes as resolved!

Thanks

[Richard (richard-redhat-bugs)]

(In reply to comment #27)
> And it seems to work. My thinkpad stays awake on removal of AC power even
after the LID has been closed/re-opened once. So this is great news!

Yay! thanks.

> One thing i noticed, that I'm not at all certain is related or even a bug, was
> that immediately after resume from suspend to memory, if i unplug the AC
> adapter, i get no notification "bubbles". Like i said, i'm not sure what may be
> causing this or if it's even a problem - i just thought i'd mention it, now that
> i noticed.

I'm not sure, but I don't think it's related. You only suppost to get the
notification if you go from 95% to any higher, to avoid getting notified if you
plug in and then repeat at few times at > 95%.

> From my pov, this bug can be closes as resolved!

Sweet. I'll release 2.14.3 (doh) today and then rh can do an update.

Thanks for the quick response.

Richard.

[John (john-redhat-bugs)]

Richard,

Nice work. Should I apply the patch to the RPM's or wait for a new release?

[Richard (richard-redhat-bugs)]

J5, I'll release 2.14.3 in a few hours, and then pls package that as an update.
Thanks.

[Richard (richard-redhat-bugs)]

2.14.3 has been released, which should be pushed to updates IMO. Thanks.

[Byeong-Taek (byeong-taek-redhat-bugs)]

Created attachment 128235
verbose messages during unexpected suspend

I got cvs HEAD right now.
Of course, I patched hal script.
But still I have no luck.
Here is outputs from g-p-m.

[Richard (richard-redhat-bugs)]

You tested too quickly, i.e. started g-p-m and then shut the lid straight away:

[lid_button_pressed] gpm-manager.c:1373 (20:33:49): lid button CLOSED
[gpm_screensaver_enable_[lid_button_pressed] gpm-manager.c:1373 (20:33:49): lid
button CLOSED
[gpm_screensaver_enable_throttle] gpm-screensaver.c:225 (20:33:49):
setThrottleEnabled : 1
[lid_button_pressed] gpm-manager.c:1391 (20:33:49): Performing AC policy
[manager_policy_do] gpm-manager.c:692 (20:33:49): policy:
/apps/gnome-power-manager/action_ac_button_lid
[gpm_manager_is_policy_timout_valid] gpm-manager.c:198 (20:33:49): Skipping
suppressed policy eventthrottle] gpm-screensaver.c:225 (20:33:49):
setThrottleEnabled : 1
[lid_button_pressed] gpm-manager.c:1391 (20:33:49): Performing AC policy
[manager_policy_do] gpm-manager.c:692 (20:33:49): policy:
/apps/gnome-power-manager/action_ac_button_lid
[gpm_manager_is_policy_timout_valid] gpm-manager.c:198 (20:33:49): Skipping
suppressed policy event

You need to wait 5 seconds before you can do any "event" from starting up g-p-m.
You can probably reduce this in your case by reducing the value of
/apps/gnome-power-manager/policy_supression_timeout in gconf editor.

We should probably reduce the default value of that to 2 seconds, rather than 5,
feel free to create a bug in gnome bugzilla if this fixes the issue for you.

Richard.

[Fedora (fedora-redhat-bugs)]

gnome-power-manager-2.14.3-1 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.

[Byeong-Taek (byeong-taek-redhat-bugs)]

Richard,

I have the same error although I wait enough.
If you want, I will upload the new message.
At this time, I will not upload it because the new file has redundant information.

[Byeong-Taek (byeong-taek-redhat-bugs)]

I think I realized why this problem happens at least on my laptop.
After resume, still lid state information at /proc shows to me 'closed'.
With the wrong information, g-p-m starts to suspend when unplugged ac.
Maybe g-p-m decides if it starts to suspend or not, with state information not
event information, right?

[Richard (richard-redhat-bugs)]

btlee, I think you have an acpi problem. If you shut the lid, then wait a
minute, then open the lid, how long before the /proc/../state key says "open" again?

I think in future versions of g-p-m i'll provide a way of saying "I don't have a
lid button that works" in gconf or something. Not sure yet.

[Byeong-Taek (byeong-taek-redhat-bugs)]

Sometimes, closing the lid couldn't suspend mylaptop.
Now, I figured it out.
Evidently, at that time, g-p-m could not suspend it because the information of
lid is "open".
Well..
Actually, I removed some code from gpm-manager.c, and it works now.
Due to the patch, g-p-m can't make laptop suspend while the lid is closed.
It seems to be more reasonable, but I'n not sure if you agree with me. :)

[Richard (richard-redhat-bugs)]

btlee: just change the lid action for 'on battery' and 'on ac' to "Do nothing"
and then you should be okay.

[Byeong-Taek (byeong-taek-redhat-bugs)]

Richard,

Above all, thanks for your concern.
But, if i change as you told me, I cannot make laptop suspend by closing the lid.
Only click of suspend menu could make it suspend.
It's not what I want.

[John (john-redhat-bugs)]

I have released the new versions of HAL and g-p-m to FC-5 Testing. Please grab
the rpm's from there. They should be moved to final update tomorow night if no
one complains.

[Fedora (fedora-redhat-bugs)]

gnome-power-manager-2.14.3-1 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.

[Christian Holtje (docwhat)]

I have what seems to be a the same problem:
I have g-p-m configured suchly:
  On AC: When Lid is Closed: Hibernate
  On Battery: When Lid is Closed: Hibernate

I have suspended my laptop successfully by closing the lid.
If I do the following:
  plug in power
  resume
  pull power
THEN it hibernates (full battery)

However, I cannot get the same behaviour by doing this:
  unplug power
  resume
  plug in power

Changing "On Battery: When Lid is Closed" to "Nothing" causes this
behaviour:
  plug in power
  resume
  pull power
THEN it does nothing.

I tried the fixes mentioned by Richard Hughes at
http://live.gnome.org/GnomePowerManager/Faq the item called "My laptop suspended when I didn't expect it to when I removed the
power cord!"

Versions:
 hal 0.5.7-1ubuntu11
 power-manager 0.1.1-2
 gnome-power-manager 2.14.3-0ubuntu1

I'm willing to play around with this. I thought I grokked the acpi/acpid packages, but what hal and dbus are doing, I don't understand.

Ciao!

[Rod (rod-redhat-bugs)]

This problem (suspend when remove AC) seems to be fixed on my Thinkpad T41 with
very limited testing.

However the issue in 183709 (re-suspend when resuming) is not.

[Daniel Silverstone (dsilvers)]

gnome-power-manager (2.14.3-0ubuntu2) dapper; urgency=low

  * Patches added in this version:
    - 20-enable-xfce-startup.patch
      Enable XFCE in the .desktop file so that it starts up for xubuntu too.
      Closes: launchpad #43077
    - 30-transparent-notification-icon.patch
      Enable the eggtrayicon stuff to do transparency.
      Closes: launchpad #40446
    - 95-lid-state-tracking.patch
      Augment lid state tracking to use hal if hal reports it is capable
      of tracking the lid state.
      If hal reports an acpi_LID with button.has_state == true then we use
      that state information whenever we want to consider the lid switch
      This should deal with LP #33072 and thus its duplicates #42988,
      #42823, #40730, #40662, #37442, #36459 and #33952
    - 96-disable-session-save-on-shutdown.patch
      Disable the saving of the session during critical power shutdown.
      This confuses too many people for now.
      Closes: launchpad #35691
  * Patches changed in this version:
    - 40-ubuntu-schema-defaults.patch
      Alter screen lock defaults to always lock, regardless of screensaver.
      Closes: launchpad #39448
  * Related fixes: #35591 -- We believe this is caused by the hal and
    gnome-power-manager interaction wrt. lid status. The new hal and the
    2.14.3 gnome-power-manager should fix it all.

[BrendanWood (brendan-spaga)]

I just upgraded my laptop (compaq presario v2000) to dapper (from Breezy) and now my machine is going into suspend when I pull the power cord. I have never seen this behavior until going to dapper.

I am happy to provide any debug/log/whatever output to help troubleshoot.

This is somewhat annoying (to say the least).

[Matthew East (mdke)]

Brendan: It might be worth filing a separate bug for this. This bug is fixed for lots of users so it is likely that your problem has a slightly different cause.

Attach the output of "gnome-power-manager --no-daemon --verbose" when reproducing the bug.

[dennis (dwavomba)]

This bug is still present on my sony vaio vgn-fs790. I have found various crude methods around it. The bug can be reproduced without fail (on my laptop at least) by following these steps:
1. Allow the battery to fully charge.
2. Put the laptop on hibernate (suspend to disk) or suspend to ram by closing the lid.
3. Detach the ac chord - while still in suspend
4. Open the lid and revive

After step 4, the laptop will come back on but quickly go back into suspend. After reviving it again it works fine. Since this is very annoying, I usually never allow my battery to fully charge (I leave it at around 96% then remove the ac chord). Also, just incase I forget to do that, I set g-p-m to always suspend to ram since its much faster to bring the laptop back to life.

Of course g-p-m never shows the correct "minutes remaining number" (a common bug) albeit it shows the correct percentage remaining. I agree, this can be annoying and I hope they find a fix soon.

NB: I have a fresh dapper install with full updates. Let me know in what other ways I could help. Thanks

[BrendanWood (brendan-spaga)]

Here is the complete output while running in verbose mode:

http://www.datacake.org/~woodb/gpm/g-p-m-output.txt

This behavior was not there before dapper and I was running g-p-m in Breezy. I can also tell gpm to blank the screen when the lid is closed and the screen will blank when I pull the AC cord. Less annoying I suppose.

g-p-m is seeing the AC power cord pull as a lid event.

Thanks,
B

[Richard Hughes (richard-hughes)]

2006-04-24 Richard Hughes <email address hidden>

 * tools/hal-system-power-hibernate, tools/hal-system-power-suspend:
 Add --print-reply to dbus-send else the Rescan does not work.
 This should fix a whole load of bugs related to ACPI values on resume.

[Richard Hughes (richard-hughes)]

>g-p-m is seeing the AC power cord pull as a lid event.

What does lshal -m say when you remove the ac_adapter?

[Richard Hughes (richard-hughes)]

>Of course g-p-m never shows the correct "minutes remaining number" (a common bug) albeit it >shows the correct percentage remaining. I agree, this can be annoying and I hope they find a fix >soon.

This is the real source of your bug.

For a quickfix you could try: http://live.gnome.org/GnomePowerManager/Faq#head-d63311e4e7dcd64f6e2e23bcd570525e33847f0e

Hope that helps,

Richard.

[BrendanWood (brendan-spaga)]

Here is the output of lshal -m when it happens:

woodb@swr512:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
acpi_BAT0 property battery.remaining_time removed
acpi_BAT0 property battery.charge_level.last_full = 44915200 (0x2ad5a00)
acpi_BAT0 property battery.charge_level.current = 30067200 (0x1caca00)
acpi_BAT0 property battery.voltage.current = 11600 (0x2d50)
acpi_BAT0 property battery.rechargeable.is_charging = false
acpi_ACAD property ac_adapter.present = false
acpi_BAT0 property battery.charge_level.last_full = 45182368 (0x2b16da0)
acpi_BAT0 property battery.charge_level.current = 30246048 (0x1cd84a0)
acpi_BAT0 property battery.voltage.current = 11669 (0x2d95)
net_00_c0_9f_a3_06_5c removed
net_00_12_f0_7c_fc_e7 removed
acpi_ACAD property ac_adapter.present = true
acpi_BAT0 property battery.charge_level.last_full = 45875456 (0x2bc0100)
acpi_BAT0 property battery.charge_level.current = 30710016 (0x1d49900)
acpi_BAT0 property battery.voltage.current = 11848 (0x2e48)
usb_device_46d_c00b_noserial_if0_logicaldev_input removed
usb_device_46d_c00b_noserial_if0 removed
usb_device_46d_c00b_noserial_usbraw removed
acpi_PWRF condition ButtonPressed = power
usb_device_46d_c00b_noserial removed
usb_device_46d_c00b_noserial added
usb_device_3f0_11d_noserial_if0_bluetooth_hci removed
usb_device_46d_c00b_noserial_if0 added
usb_device_3f0_11d_noserial_if0 removed
usb_device_3f0_11d_noserial_if1 removed
usb_device_3f0_11d_noserial_if2 removed
usb_device_3f0_11d_noserial_if3 removed
usb_device_3f0_11d_noserial_usbraw removed
usb_device_3f0_11d_noserial removed
usb_device_46d_c00b_noserial_usbraw added
usb_device_46d_c00b_noserial_if0_logicaldev_input added
net_00_c0_9f_a3_06_5c added
usb_device_3f0_11d_noserial added
usb_device_3f0_11d_noserial_if0 added
usb_device_3f0_11d_noserial_if1 added
usb_device_3f0_11d_noserial_if2 added
usb_device_3f0_11d_noserial_if3 added
net_00_12_f0_7c_fc_e7 added
usb_device_3f0_11d_noserial_if0_bluetooth_hci added
usb_device_3f0_11d_noserial_usbraw added
acpi_BAT0 property battery.remaining_time = 637 (0x27d) (new)
acpi_BAT0 property battery.charge_level.last_full = 47327456 (0x2d228e0)
acpi_BAT0 property battery.charge_level.current = 31682016 (0x1e36de0)
acpi_BAT0 property battery.voltage.current = 12223 (0x2fbf)
acpi_BAT0 property battery.rechargeable.is_charging = true

..one thing (*I think*) I have noticed is that to trigger it, there must be a suspend action without power and then resume happens with power already plugged in. If I suspend with power and then resume with power, the behavior doesn't happen at next AC cord pull. Odd.

I'll keep trying to diagnose what exactly the behavior patterns are.

Thanks again for looking at this :) You guys rock.

[dennis (dwavomba)]

Thanks for the tip Richard,

The fix was helpful - at least g-p-m doesn't keep warning me that I have
4min left when I'm at 99% charge. This however, doesn't fix the erratic
"suspend when ac cable unplugged" problem.

Dennis

Richard Hughes wrote:
>> Of course g-p-m never shows the correct "minutes remaining number" (a
> common bug) albeit it >shows the correct percentage remaining. I agree,
> this can be annoying and I hope they find a fix >soon.
>
> This is the real source of your bug.
>
> For a quickfix you could try:
> http://live.gnome.org/GnomePowerManager/Faq#head-
> d63311e4e7dcd64f6e2e23bcd570525e33847f0e
>
> Hope that helps,
>
> Richard.
>

[Martin Pitt (pitti)]

Easy upstream hal fix

[Martin Pitt (pitti)]

This does not affect the current edgy version.

[Daniel (daniel-redhat-bugs)]

Closing bugs

[bj mccormick (bjmccormick)]

This is still happening for me on gutsy. Should I be worried? Worked fine in feisty. On a system76 darter 1.

[Justin Sunseri (jmsunseri)]

I have not had this problem in ages with feisty or gutsy. I thought this
ticket was closed.

On 10/10/07, bj mccormick <email address hidden> wrote:
>
> This is still happening for me on gutsy. Should I be worried? Worked
> fine in feisty. On a system76 darter 1.
>
> --
> Pulling AC plug suspends computer
> https://bugs.launchpad.net/bugs/33072
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Sincerely

Justin Sunseri

[u-foka (ufooka)]

Hy!

I have this bug in maverick beta! Should I open a new bug? And what Information should I report?
I have a Dell Vostro 1310..

[Jan Smith (johsmi9933)]

This happens consistently every time on my laptop running Ubuntu 20.04.1 LTS.
I keep it running with the lid open and the AC power cable connected, when I unplug the cable Ubuntu auto-suspends (battery is well over 90%). Extremely annoying.

The power settings are:
* Automatic suspend when on battery power