Bug 187396 - hibernate when unplugged the ac adapter
hibernate when unplugged the ac adapter
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
: 187512 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-30 13:23 EST by Teguh DC
Modified: 2013-03-05 22:45 EST (History)
10 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-28 16:05:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gpm verbose trace (7.24 KB, text/plain)
2006-03-31 10:07 EST, David L.
no flags Details
full gpm verbose output (122.94 KB, text/plain)
2006-03-31 12:55 EST, David L.
no flags Details
gnome-power-manager-2.14.1-dont-suspend-on-ac-unplug.patch (703 bytes, patch)
2006-04-24 14:39 EDT, Bastien Nocera
no flags Details | Diff
output of lshal -m for the duration of the test (3.14 KB, text/plain)
2006-04-24 20:19 EDT, Thomas M Steenholdt
no flags Details
gpm 2.14.2 verbose log for the duration of the test (88.81 KB, text/plain)
2006-04-24 20:20 EDT, Thomas M Steenholdt
no flags Details
fix that works for me (5.42 KB, patch)
2006-04-25 05:25 EDT, Richard Hughes
no flags Details | Diff
same patch against 2-14 (5.09 KB, patch)
2006-04-25 05:38 EDT, Richard Hughes
no flags Details | Diff
verbose messages during unexpected suspend (36.58 KB, text/plain)
2006-04-25 23:29 EDT, Byeong-Taek Lee
no flags Details

  None (edit)
Description Teguh DC 2006-03-30 13:23:10 EST
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
Comment 1 Richard Hughes 2006-03-30 13:35:21 EST
As root, can you do:

cat /var/log/messages | grep gnome

and reply with the output here.

Thanks.
Comment 2 Teguh DC 2006-03-30 22:59:47 EST
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
Comment 3 Richard Hughes 2006-03-31 04:39:44 EST
Can you grab me a g-p-m verbose trace when this happens please. Thanks.
Comment 4 David L. 2006-03-31 10:07:57 EST
Created attachment 127129 [details]
gpm verbose trace
Comment 5 Richard Hughes 2006-03-31 11:25:28 EST
*** Bug 187512 has been marked as a duplicate of this bug. ***
Comment 6 Richard Hughes 2006-03-31 11:30:19 EST
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.
Comment 7 Richard Hughes 2006-03-31 11:37:21 EST
Also, I need the complete gpm verbose trace, including the initialisation stuff.
Thanks.
Comment 8 Daniel Walsh 2006-03-31 11:38:42 EST
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
Comment 9 David L. 2006-03-31 12:55:07 EST
Created attachment 127140 [details]
full gpm verbose output
Comment 10 Richard Hughes 2006-04-01 03:02:45 EST
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.
Comment 11 David L. 2006-04-01 08:25:06 EST
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? 


Comment 12 Rod Nayfield 2006-04-07 08:53:09 EDT
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

Comment 13 Koichi Takahashi 2006-04-11 23:54:36 EDT
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

Comment 14 Richard Hughes 2006-04-24 13:58:49 EDT
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.
Comment 15 Bastien Nocera 2006-04-24 14:39:56 EDT
Created attachment 128162 [details]
gnome-power-manager-2.14.1-dont-suspend-on-ac-unplug.patch

Patch version
Comment 16 Bastien Nocera 2006-04-24 14:41:30 EDT
That patch, along with Richard's in comment #14 fixes the problem for me.
Comment 17 Bastien Nocera 2006-04-24 14:43:51 EDT
i386 RPMs:
http://files.hadess.net/redhat/rawhide/i386/
and sources:
http://files.hadess.net/redhat/rawhide/source/
Comment 18 Richard Hughes 2006-04-24 14:49:52 EDT
Committed to 2-14 and HEAD:

2006-04-24  Richard Hughes  <richard@hughsie.com>
 * 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.
Comment 19 Thomas M Steenholdt 2006-04-24 20:18:01 EDT
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...
Comment 20 Thomas M Steenholdt 2006-04-24 20:19:33 EDT
Created attachment 128169 [details]
output of lshal -m for the duration of the test
Comment 21 Thomas M Steenholdt 2006-04-24 20:20:52 EDT
Created attachment 128170 [details]
gpm 2.14.2 verbose log for the duration of the test
Comment 22 Richard Hughes 2006-04-25 04:45:44 EDT
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.
Comment 23 Richard Hughes 2006-04-25 05:25:27 EDT
Created attachment 128189 [details]
fix that works for me

Thomas, can you try the attached patch agains CVS head pls. It seems to work
for me.
Comment 24 Richard Hughes 2006-04-25 05:39:00 EDT
Created attachment 128190 [details]
same patch against 2-14

This is the same patch against 2-14 if CVS scares you.
Comment 25 David L. 2006-04-25 06:11:40 EDT
the patch from #24 finally does the trick for me
Comment 26 Richard Hughes 2006-04-25 06:15:17 EDT
Thanks for testing that David, if they work for Thomas also, I'll commit both to
the respective branches.
Comment 27 Thomas M Steenholdt 2006-04-25 07:57:47 EDT
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
Comment 28 Richard Hughes 2006-04-25 08:20:57 EDT
(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.
Comment 29 John (J5) Palmieri 2006-04-25 10:29:03 EDT
Richard,

Nice work.  Should I apply the patch to the RPM's or wait for a new release?
Comment 30 Richard Hughes 2006-04-25 12:11:14 EDT
J5, I'll release 2.14.3 in a few hours, and then pls package that as an update.
Thanks.
Comment 31 Richard Hughes 2006-04-25 12:12:08 EDT
J5, I'll release 2.14.3 in a few hours, and then pls package that as an update.
Thanks.
Comment 32 Richard Hughes 2006-04-25 19:06:44 EDT
2.14.3 has been released, which should be pushed to updates IMO. Thanks.
Comment 33 Byeong-Taek Lee 2006-04-25 23:29:25 EDT
Created attachment 128235 [details]
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.
Comment 34 Richard Hughes 2006-04-26 03:00:27 EDT
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.
Comment 35 Fedora Update System 2006-04-26 17:15:43 EDT
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.
Comment 36 Byeong-Taek Lee 2006-04-26 22:21:15 EDT
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.
Comment 37 Byeong-Taek Lee 2006-04-26 23:04:43 EDT
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?
Comment 38 Richard Hughes 2006-04-27 03:13:59 EDT
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.
Comment 39 Byeong-Taek Lee 2006-04-27 03:28:16 EDT
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. :)
Comment 40 Richard Hughes 2006-04-27 03:35:43 EDT
btlee: just change the lid action for 'on battery' and 'on ac' to "Do nothing"
and then you should be okay.
Comment 41 Byeong-Taek Lee 2006-04-27 03:43:08 EDT
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.
Comment 42 John (J5) Palmieri 2006-04-27 13:28:48 EDT
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.
Comment 43 Fedora Update System 2006-05-04 14:06:38 EDT
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.
Comment 44 Rod Nayfield 2006-05-05 09:39:56 EDT
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.

Comment 45 Daniel Walsh 2007-03-28 16:05:39 EDT
Closing bugs

Note You need to log in before you can comment on or make changes to this bug.