Bug 475585

Created attachment 326425 [details]
Suspend log after the system does wake up

-rw-r--r-- 1 root    root         6329 2008-12-09 17:46 pm-suspend.log

Created attachment 326426 [details]
Powersave log after the system does wake up

-rw-r--r-- 1 root    root           89 2008-12-09 17:46 pm-powersave.log

Created attachment 326427 [details]
Section of /var/log/messages showing initial suspend and resume related behavior

Section of /var/log/messages from the original suspend and then watching the system bounce.  Needed to cycle only twice this time: initial wake, which went back to sleep, and then once more for it to stick.

Matt seems to believe that it is gnome-power-manager related, so having read
all of the open defects against gnome-power-manager in upstream, and finding
one that describes the behavior, I've added that upstream bug.

Found another, similar, bug in upstream, although my scenario has nothing to do with hibernate; mine is purely suspend-to-RAM and resume based.

I get the same behavior.

$ uname -a
Linux ... 2.6.27.7-134.fc10.i686 #1 SMP Mon Dec 1 22:42:50 EST 2008 i686 i686 i386 GNU/Linux

My laptop is a Dell D600. When I press the key that sends the "XF86Sleep" (Fn-Esc), my machine goes into suspend. When I resume from suspend with the power button, the machine goes into suspend again. After a subsequent resume, the machine resumes for good.

If I set gnome-power-manager to "Do Nothing" when the suspend button is pressed and then suspend with 

# pm-suspend

my machine properly suspends once. pm-suspend only lists a single suspend+resume cycle when I hit the susp button. /var/log/messages shows the suspend,resume,suspend,resume

I'll attach my /var/log/messages.

Sorry if this is the wrong place to log the bug. I'm not sure which code has the responsibility of protecting against a dup suspend. Should X be responsible for disabling the suspend key event for a period of time after it is pressed once? Should the kernel handle this? Should G-P-M ignore the suspend key if it has already been pressed within a certain time period?

Created attachment 326433 [details]
relevant section from my /var/log/messages, showing repeated suspend+resume cycle

Good observations, Greg.  I can confirm what you found, and even make it fractionally simpler.

I don't change anything related to the gnome-power-manager at all.  If I simply go ahead and run pm-suspend or suspend from System->Shutdown, resume works as desired.

ONLY if I suspend with the Fn-F4 hotkey, do I go through the aforementioned redundant cycling before the system stays awake.

I can confirm this as well on a T61p.  Resume fine after System->Shutdown->Suspend, but have to attempt multiple resumes if suspended via Fn-F4.

For what its' worth, I can confirm the same behavior as Tim on a T61.  Let me know if I can provide any logs to help track this down.

I can confirm same behavior on a Samsung Q310.

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

I'm not experiencing this problem with latest kernel: 
kernel-2.6.27.15-170.2.24.fc10.i686

Linux perla 2.6.27.15-170.2.24.fc10.i686 #1 SMP Wed Feb 11 23:58:12 EST 2009 i686 i686 i386 GNU/Linux

I've applied the various F10 errata each day this last week and the problem has gone away for me as well.  I've not yet actually booted into kernel-2.6.27.15-170.2.24.fc10.i686 though, so I don't think the kernel change was what caused the fix.  I only got the kernel today and had a variety of other package updates on the 2/15, 2/17, 2/18 and today 2/19.

If I had to guess, perhaps gnome-power-manager-2.24.4-1.fc10.i386, though it's rpm package changelog:
  * Thu Feb 12 2009 Richard Hughes  <rhughes> - 2.24.4-1
  - Update to 2.24.4
  - Fixes #465444
is not particularly helpful.  I've been fairly distracted the last few days, but the activity on this bug reminds me I don't believe I've seen the problem for more than a few days, and this gnome-power-manager errata was installed on my laptop on 2/15.

Before closing this bug, somebody should probably dig through the gnome-power-manager changelog for 2.24.4 in order to see if there's a likely explicit fix listed as opposed to the bug just having hid itself somewhere.

I'm running into the same bug with gnome with 2.6.29-0.43.rc6.fc10.x86_64.

This is on a T61p and using the Fn+F4 key to suspend.

I experience the very same problem (only if suspending through Fn+F4) on a ACER TravelMate 3000, even after upgrading to gnome-power-manager-2.24.4-1.fc10 and kernel-2.6.27.15-170.2.24.fc10

I also have another gnome-power-manager issue: when shutting down by pressing the power button, sometimes (but not always) the system gets stuck until I press the power button again. No problems if I use the poweroff command or the system menu to shut down.

Ugh.  No package or config changes in 5 days, but since yesterday I'm having the problem again.  So probably disregard my 2009-02-19 comment.

Using a Lenovo ThinkPad X61. Exhibits the same behaviour. However, I did notice that explicitly setting the Suspend keyboard shortcut to XF86Sleep on my X61 seems to have made the symptom disappear. The keyboard shortcut was "Disabled" on a default installation for me.

I set it at System -> Preferences -> Keyboard Shortcuts, under the Desktop section. You can set it also using gconf-editor at the key "/apps/gnome_settings_daemon/keybindings/sleep".

I noticed that upon setting this, triggering the sleep using Fn-F4, it doesn't fade out the screen like it does before (it still does using System->Shut Down->Suspend), but it immediately blanks the screen, lights it up for a moment, then suspends.

Please note that I've only tested this by quickly suspending and resuming and not for long durations as I still have to work right now. Will try extended periods when I suspend my X61 before I go home.

Just wanted to comment that while what I did gets rid of the symptom of immediately sleeping the computer again after a resume... I now get logged out of my account after extended periods of sleep. But it does get rid of the symptom.

(In reply to comment #9)
> I can confirm this as well on a T61p.  Resume fine after
> System->Shutdown->Suspend, but have to attempt multiple resumes if suspended
> via Fn-F4.  

I see this too on a Clevo M720R. No problem selecting suspend from the menus, but using the sleep button (or lid?) causes the machine to suspend immediately after resume.

(This is on F11, gnome-power-manager-2.26.3-1.fc11.x86_64.)

Confirmed on a fully updated F11 with gnome-power-manager-2.26.3-1.fc11.x86_64, installed on a Lenovo Thinkpad W500.

I am experiencing the same on my F11 Thinkpad T400.

Should the version of this Bug be updated to F11?

Could this be a problem of Xorg sending the key event again right after resume?

Me too. Never happened on Fedora 8.
Happens now on 2.6.29.6-213.fc11.i586.
Happens often when power button used to suspend.
Happens seldomly when lid closed/opened.
I think bug 495993 is the same issue.

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

same thing happens to me, 1st wake from suspend goes right back to sleep, on HP 8530w, nvidia graphics, unfortunately having to run the binary only driver to get graphics+suspend to work.

Seeing this behavior as well on a T23 running F11 when pressing Fn+F4. Usually takes 2-3 resume cycles before it resumes for good.

kernel 2.6.29.6-217.2.3.fc11.i686.PAE
gnome-power-manager-2.26.3-1.fc11.i586
xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586

Still happens with F11?

yes did a clean install of F11 on my thinkpad X31.
if i suspend using the suspend key (fn+F4), then on resume it cycle back to suspend. i think if i repeatedly press the fn key (the one needed to wake it) then it help it stay awake.

if i suspend by closing the lid, or from the system menu then it resumes fine.

Still happens with xorg-x11-server-Xorg-1.6.2-1.fc11.i586
Just tried xorg-x11-server-Xorg-1.6.3-4.fc11.i586 built yesterday
(is this why you were asking?). Unfortunately I still same issue with:

kernel 2.6.29.6-213.fc11.i586
gnome-power-manager-2.26.4-1.fc11.i586
xorg-x11-server-Xorg-1.6.3-4.fc11.i586

Worth noting again that closing by lid is usually but not always OK,
while suspending with keyboard is usually not OK.

On my ThinkPad R61, I first had F11 beta installed, which I kept up-to-date. So when F11 final was released, I thought I had something like a real F11 installation. I couldn't reproduce this bug, though.

When I installed a clean F11 final on another machine, I found out that there were a few differences between a F11 final and my updated F11 beta, even though both machines had the latest F11 packages installed.

Finally I reinstalled a clean F11 final on my R61, and got rid of the differences. But alas, now I can reproduce this bug too...

Yep. If I do a pm-suspend or suspend through gnome-power-manager it will resume fine. Suspending with Fn+F4 is the issue here.

I also saw this from time to time with a F10 install, though it was much less frequent.

This problem started for me on a Dell D410 running FC11 a couple of months ago. It was fine before that. It is still a problem with the test kernel 
2.6.30.4-25.fc11.i586

It happens consistently if I suspend with function key, and occasionally if I suspend by closing lid.

Happens consistently now in rawhide when using the lid on my notebook:

gnome-power-manager-2.28.1-2.fc12.x86_64
DeviceKit-003-2.x86_64
DeviceKit-power-012-1.fc12.x86_64
pm-utils-1.2.5-6.fc12.x86_64

A work around has been posted on Fedora Forum at the link  below:

http://forums.fedoraforum.org/showthread.php?p=1256804&posted=1#post1256804

It works on my T400.

Jim

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I believe I'm seeing this bug in Fedora 12.  I also think bugs #197007 and
#529487 are duplicates of this one.

Tore

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I'm seeing this on F11. I've not seen a specific fix mentioned.
Also others have mentioned it's still present in F12.

I am seeing this today on F12.

This happens if I suspend while plugged in, and resume after unplugging the power cord. I assume the unplug event is queuing up?

Can confirm this occurs on an up to date F12 kernel.  I have an HP 8530W with ICH9 chipset.  Roughly half the time I wake up the machine it immediately cycles back to sleep.

(In reply to comment #40)
> This happens if I suspend while plugged in, and resume after unplugging the
> power cord. I assume the unplug event is queuing up?    

Yes, this agrees with what I'm seeing.  It's *always* when I suspend with power attached; the resume will go back to sleep immediately.

I can concur that it doesn't happen (or very rarely happens) when resuming when plugged in, while often when resuming on battery, the cycle back to sleep happens. Note this is independent of whether I suspended with power attached or not. Note the system is mostly running before the erroneous cycle back to suspend. I can see the wireless applet re-establishing and I can move windows for a short while. However once I don't see the power manage applet icon displaying I know my ICH6 laptop will suspend again within a few seconds.

ubuntu have fix what may be the same bug https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/425411

gnome-power-manager (2.28.1-0ubuntu1.3) karmic-proposed; urgency=low

  * debian/patches/09-fix-double-suspend.patch:
    + Inhibit consolekit events after resuming from suspend to fix a race
      condition regarding pm-utils, uswsusp, and chvt (LP: #425411)

gnome-power-manager (2.28.1-0ubuntu1.2) karmic-proposed; urgency=low

  * debian/patches/09-fix-double-suspend.patch:
    + Fix gpm_button_is_lid_closed to return an updated value from
      DeviceKit-Power instead of its own locally stored value which may be
      outdated (LP: #425411)

gnome-power-manager (2.28.1-0ubuntu1.1) karmic-proposed; urgency=low

  * debian/patches/09-fix-double-suspend.patch:
    + Manually check lid status in gpm_manager_client_changed_cb. Fixes
      double-suspend bug (LP: #425411)
 -- Chow Loong Jin < hyperair>   Thu, 28 Jan 2010 08:26:09 +0800

Created attachment 387296 [details]
ubuntu's patch

might need this as well

devicekit-power (011-1ubuntu2) karmic-proposed; urgency=low

  * debian/patches/02-dkpclient-singleton.patch:
    - Make DkpClient a singleton to avoid strange races that can
      arise. Patch pulled from upstream Git.  (LP: #425411)
 -- Chow Loong Jin < hyperair>   Wed, 27 Jan 2010 02:02:00 +0800

The following, found on the Ubutu thread, seems to solve it for me:

Run gconf-editor and go to

/ --> apps --> gnome-power-manager --> actions

and uncheck the box labeled "event_when_closed_battery".

I'm pretty sure that this is fixed properly in F13 -- any chance somebody can try one of the pre-release ISOs and report success / failure please? Thanks.

I'm running F13 alpha with updates current as of today, and I am still seeing this problem.

Jens: did you try the solution in comment 47? It has completely solved it for me.

No, sorry about that -- I just saw Richard's comment.  I'll report back with success or failure in a week or so, after I've been able to test it for a while.

Under F13, I am still getting this.  In fact, I got this to happen *twice* in a row: I opened up my laptop, it did the immediate suspend; I opened it again, and it immediately suspended *again*.

And I have unchecked the item mentioned in comment 47.

I have a similar problem with Fedora 13 on a ThinkPad SL500. If I close the case to suspend the laptop, wait more than 30 minutes, then open the case, I see a login screen with the notice "Time has expired" and the laptop immediately suspends again. When I then press the power button, the login screen comes back and I can login normally.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This is definitely fixed for me in F14

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This issue is also fixed for me in Fedora 14.