Pulling AC plug suspends computer
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HAL |
Fix Released
|
High
|
|||
gnome-power-manager (Fedora) |
Fix Released
|
Medium
|
|||
gnome-power-manager (Ubuntu) |
Fix Released
|
Medium
|
Daniel Silverstone | ||
hal (Ubuntu) |
Fix Released
|
Medium
|
Martin Pitt |
Bug Description
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) wrote : | #1 |
DanH (holmsand-gmail) wrote : | #2 |
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-
And I have no idea why it suspends...
Log output follow:
[watch_
[watch_
[watch_
[hal_button_
[power_
[lid_button_
[lid_button_
[manager_policy_do] gpm-manager.c:575 (22:53:14): policy: /apps/gnome-
[manager_policy_do] gpm-manager.c:596 (22:53:14): *ACTION* Suspend
[manager_
[gpm_screensave
*** 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
*** WARNING ***
[gpm_tray_
[get_widget_
*** WARNING ***
[libnotify_event] gpm-tray-icon.c:631 (22:53:38): libnotify: Power Manager : Your computer failed to suspend.
Check the <a href="http://
*** WARNING ***
[gpm_screensave
[session_
[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_
[x11_sync_
[x11_sync_
[x11_sync_
[hal_device_
*** WARNING ***
[watch_
Richard Hughes (richard-hughes) wrote : | #3 |
Thanks for the log:
[power_
[manager_policy_do] gpm-manager.c:575 (22:53:59): policy: /apps/gnome-
[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-
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) wrote : | #4 |
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) wrote : | #5 |
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-
And I can assure you that I wont be filing any more bugs against them. Plain xscreensaver/
Thank you for validating my choice.
Richard Hughes (richard-hughes) wrote : | #6 |
>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) wrote : | #7 |
DanH: Can you please confirm if this is fixed in 2.13.92-0ubuntu1 ?
Paul Sladen (sladen) wrote : | #8 |
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) wrote : | #9 |
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) wrote : | #10 |
Daniel, which patch linked? Thanks.
Daniel Silverstone (dsilvers) wrote : | #11 |
Fixed in 2.13.93-0ubuntu1
Changed in gnome-power-manager: | |
assignee: | nobody → dsilvers |
status: | Unconfirmed → Fix Released |
Reinhard Tartler (siretart) wrote : | #12 |
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.
Changed in gnome-power-manager: | |
status: | Fix Released → Unconfirmed |
Reinhard Tartler (siretart) wrote : | #13 |
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) wrote : | #14 |
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.
In Red Hat Bugzilla #187396, Teguh (teguh-redhat-bugs) wrote : | #46 |
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-
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
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #47 |
As root, can you do:
cat /var/log/messages | grep gnome
and reply with the output here.
Thanks.
In Red Hat Bugzilla #187396, Teguh (teguh-redhat-bugs) wrote : | #48 |
Here the output ..
Mar 31 11:02:25 gazebo gnome-power-
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) wrote : | #15 |
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.
Changed in gnome-power-manager: | |
status: | Unconfirmed → Confirmed |
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #49 |
Can you grab me a g-p-m verbose trace when this happens please. Thanks.
In Red Hat Bugzilla #187396, David (david-redhat-bugs) wrote : | #50 |
Created attachment 127129
gpm verbose trace
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #51 |
*** Bug 187512 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #52 |
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.
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #53 |
Also, I need the complete gpm verbose trace, including the initialisation stuff.
Thanks.
In Red Hat Bugzilla #187396, Daniel (daniel-redhat-bugs) wrote : | #54 |
Start monitoring devicelist:
-------
acpi_AC property ac_adapter.present = false
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_AC property ac_adapter.present = true
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
In Red Hat Bugzilla #187396, David (david-redhat-bugs) wrote : | #55 |
Created attachment 127140
full gpm verbose output
Richard Ferguson (ufergus) wrote : | #16 |
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.
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #56 |
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:/
You don't have to recompile anything.
Thanks.
In Red Hat Bugzilla #187396, David (david-redhat-bugs) wrote : | #57 |
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.
When the lid is open, and hal is confused I get:
lshal -l | grep button.state
button.
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) wrote : | #17 |
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) wrote : | #18 |
I thought this was fixed, but I just ran into it again. 2.14.0-1.
In Red Hat Bugzilla #187396, Rod (rod-redhat-bugs) wrote : | #58 |
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-
lid has been closed on ac power
Disconnect AC and open lid, then:
Apr 6 16:42:22 localhost gnome-power-
lid has been closed, and the ac adapter removed
Sébastien MURER (MuMu) (seb-murer) wrote : | #19 |
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 ! :-)
In freedesktop.org Bugzilla #6542, Lowe-brown (lowe-brown) wrote : | #20 |
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.
[root@trillian lowe]# cat /proc/acpi/
state: open
However, after hibernating (by closing the lid) and resuming, they disagree
[root@trillian lowe]# lshal -l | grep button.state
button.
[root@trillian lowe]# cat /proc/acpi/
state: open
I am using hal version 0.5.7 plus the patch for hal-system-
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://
In Red Hat Bugzilla #187396, Koichi (koichi-redhat-bugs) wrote : | #59 |
It seems there are more then one issues here, but
changing line 1220 of gpm-manager.c from
if (! on_ac && manager-
to
if ( (! on_ac) && manager-
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-
>
> 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) wrote : verbose log | #21 |
- verbose log Edit (66.4 KiB, text/html)
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) wrote : | #22 |
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. :)
In freedesktop.org Bugzilla #6542, Thomas M Steenholdt (tmus) wrote : | #23 |
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-
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) wrote : /var/log/acpid, lshal -m, gnome-power-manager --verbose --no-daemon | #24 |
- /var/log/acpid, lshal -m, gnome-power-manager --verbose --no-daemon Edit (6.8 KiB, text/plain)
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) wrote : | #25 |
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) wrote : | #26 |
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) wrote : | #27 |
Richard, the output is empty.
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #60 |
I've fixed the hal side of the problem:
See the first entry here: http://
Koichi, I think you may hae found *another* bug, but I'll look in more detail later.
Richard Hughes (richard-hughes) wrote : | #28 |
I've fixed the hal side of the problem:
See the first entry here: http://
In Red Hat Bugzilla #187396, Bastien (bastien-redhat-bugs) wrote : | #61 |
Created attachment 128162
gnome-power-
Patch version
In Red Hat Bugzilla #187396, Bastien (bastien-redhat-bugs) wrote : | #62 |
That patch, along with Richard's in comment #14 fixes the problem for me.
In Red Hat Bugzilla #187396, Bastien (bastien-redhat-bugs) wrote : | #63 |
i386 RPMs:
http://
and sources:
http://
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #64 |
Committed to 2-14 and HEAD:
2006-04-24 Richard Hughes <email address hidden>
* src/gpm-manager.c (power_
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.
In Red Hat Bugzilla #187396, Thomas (thomas-redhat-bugs) wrote : | #65 |
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...
In Red Hat Bugzilla #187396, Thomas (thomas-redhat-bugs) wrote : | #66 |
Created attachment 128169
output of lshal -m for the duration of the test
In Red Hat Bugzilla #187396, Thomas (thomas-redhat-bugs) wrote : | #67 |
Created attachment 128170
gpm 2.14.2 verbose log for the duration of the test
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #68 |
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.
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #69 |
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.
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #70 |
Created attachment 128190
same patch against 2-14
This is the same patch against 2-14 if CVS scares you.
In Red Hat Bugzilla #187396, David (david-redhat-bugs) wrote : | #71 |
the patch from #24 finally does the trick for me
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #72 |
Thanks for testing that David, if they work for Thomas also, I'll commit both to
the respective branches.
In Red Hat Bugzilla #187396, Thomas (thomas-redhat-bugs) wrote : | #73 |
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
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #74 |
(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.
In Red Hat Bugzilla #187396, John (john-redhat-bugs) wrote : | #75 |
Richard,
Nice work. Should I apply the patch to the RPM's or wait for a new release?
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #76 |
J5, I'll release 2.14.3 in a few hours, and then pls package that as an update.
Thanks.
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #78 |
2.14.3 has been released, which should be pushed to updates IMO. Thanks.
In Red Hat Bugzilla #187396, Byeong-Taek (byeong-taek-redhat-bugs) wrote : | #79 |
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.
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #80 |
You tested too quickly, i.e. started g-p-m and then shut the lid straight away:
[lid_button_
[gpm_screensave
button CLOSED
[gpm_screensave
setThrottleEnabled : 1
[lid_button_
[manager_policy_do] gpm-manager.c:692 (20:33:49): policy:
/apps/gnome-
[gpm_manager_
suppressed policy eventthrottle] gpm-screensaver
setThrottleEnabled : 1
[lid_button_
[manager_policy_do] gpm-manager.c:692 (20:33:49): policy:
/apps/gnome-
[gpm_manager_
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-
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.
In Red Hat Bugzilla #187396, Fedora (fedora-redhat-bugs) wrote : | #81 |
gnome-power-
In Red Hat Bugzilla #187396, Byeong-Taek (byeong-taek-redhat-bugs) wrote : | #82 |
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.
In Red Hat Bugzilla #187396, Byeong-Taek (byeong-taek-redhat-bugs) wrote : | #83 |
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?
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #84 |
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.
In Red Hat Bugzilla #187396, Byeong-Taek (byeong-taek-redhat-bugs) wrote : | #85 |
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. :)
In Red Hat Bugzilla #187396, Richard (richard-redhat-bugs) wrote : | #86 |
btlee: just change the lid action for 'on battery' and 'on ac' to "Do nothing"
and then you should be okay.
In Red Hat Bugzilla #187396, Byeong-Taek (byeong-taek-redhat-bugs) wrote : | #87 |
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.
In Red Hat Bugzilla #187396, John (john-redhat-bugs) wrote : | #88 |
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.
Changed in hal: | |
status: | Unconfirmed → Confirmed |
In Red Hat Bugzilla #187396, Fedora (fedora-redhat-bugs) wrote : | #89 |
gnome-power-
Christian Holtje (docwhat) wrote : | #29 |
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://
power cord!"
Versions:
hal 0.5.7-1ubuntu11
power-manager 0.1.1-2
gnome-
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!
In Red Hat Bugzilla #187396, Rod (rod-redhat-bugs) wrote : | #90 |
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) wrote : | #30 |
gnome-power-manager (2.14.3-0ubuntu2) dapper; urgency=low
* Patches added in this version:
- 20-enable-
Enable XFCE in the .desktop file so that it starts up for xubuntu too.
Closes: launchpad #43077
- 30-transparent-
Enable the eggtrayicon stuff to do transparency.
Closes: launchpad #40446
- 95-lid-
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-
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-
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-
2.14.3 gnome-power-manager should fix it all.
Changed in gnome-power-manager: | |
status: | Confirmed → Fix Released |
BrendanWood (brendan-spaga) wrote : | #31 |
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) wrote : | #32 |
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-
dennis (dwavomba) wrote : | #33 |
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) wrote : | #34 |
Here is the complete output while running in verbose mode:
http://
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
In freedesktop.org Bugzilla #6542, Richard Hughes (richard-hughes) wrote : | #36 |
2006-04-24 Richard Hughes <email address hidden>
* tools/hal-
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) wrote : | #37 |
>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) wrote : | #38 |
>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://
Hope that helps,
Richard.
BrendanWood (brendan-spaga) wrote : | #39 |
Here is the output of lshal -m when it happens:
woodb@swr512:~$ lshal -m
Start monitoring devicelist:
-------
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_ACAD property ac_adapter.present = false
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
net_00_
net_00_
acpi_ACAD property ac_adapter.present = true
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
usb_device_
usb_device_
usb_device_
acpi_PWRF condition ButtonPressed = power
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
net_00_
usb_device_
usb_device_
usb_device_
usb_device_
usb_device_
net_00_
usb_device_
usb_device_
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
acpi_BAT0 property battery.
..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) wrote : Re: [Bug 33072] Re: Pulling AC plug suspends computer | #40 |
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://
> d63311e4e7dcd64
>
> Hope that helps,
>
> Richard.
>
Changed in gnome-power-manager: | |
status: | Unknown → Fix Committed |
Martin Pitt (pitti) wrote : | #41 |
Easy upstream hal fix
Changed in hal: | |
assignee: | nobody → pitti |
status: | Confirmed → In Progress |
Martin Pitt (pitti) wrote : | #42 |
This does not affect the current edgy version.
Changed in hal: | |
status: | In Progress → Fix Released |
In Red Hat Bugzilla #187396, Daniel (daniel-redhat-bugs) wrote : | #91 |
Closing bugs
Changed in gnome-power-manager: | |
status: | Fix Committed → Fix Released |
bj mccormick (bjmccormick) wrote : | #43 |
This is still happening for me on gutsy. Should I be worried? Worked fine in feisty. On a system76 darter 1.
Justin Sunseri (jmsunseri) wrote : | #44 |
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:/
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
--
Sincerely
Justin Sunseri
Changed in hal: | |
importance: | Unknown → High |
u-foka (ufooka) wrote : | #45 |
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..
Changed in hal: | |
importance: | High → Unknown |
Changed in hal: | |
importance: | Unknown → High |
Changed in gnome-power-manager (Fedora): | |
importance: | Unknown → Medium |
Jan Smith (johsmi9933) wrote : | #92 |
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
What version g-p-m? Do you know why it suspends? What does the verbose log print when it suspends? Thanks.