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
As root, can you do: cat /var/log/messages | grep gnome and reply with the output here. Thanks.
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
Can you grab me a g-p-m verbose trace when this happens please. Thanks.
Created attachment 127129 [details] gpm verbose trace
*** Bug 187512 has been marked as a duplicate of this bug. ***
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.
Also, I need the complete gpm verbose trace, including the initialisation stuff. Thanks.
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
Created attachment 127140 [details] full gpm verbose output
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.
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?
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
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
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.
Created attachment 128162 [details] gnome-power-manager-2.14.1-dont-suspend-on-ac-unplug.patch Patch version
That patch, along with Richard's in comment #14 fixes the problem for me.
i386 RPMs: http://files.hadess.net/redhat/rawhide/i386/ and sources: http://files.hadess.net/redhat/rawhide/source/
Committed to 2-14 and HEAD: 2006-04-24 Richard Hughes <richard> * 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.
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...
Created attachment 128169 [details] output of lshal -m for the duration of the test
Created attachment 128170 [details] gpm 2.14.2 verbose log for the duration of the test
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.
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.
Created attachment 128190 [details] same patch against 2-14 This is the same patch against 2-14 if CVS scares you.
the patch from #24 finally does the trick for me
Thanks for testing that David, if they work for Thomas also, I'll commit both to the respective branches.
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 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.
Richard, Nice work. Should I apply the patch to the RPM's or wait for a new release?
J5, I'll release 2.14.3 in a few hours, and then pls package that as an update. Thanks.
2.14.3 has been released, which should be pushed to updates IMO. Thanks.
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.
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.
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.
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.
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?
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.
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. :)
btlee: just change the lid action for 'on battery' and 'on ac' to "Do nothing" and then you should be okay.
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.
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.
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.
Closing bugs