Red Hat Bugzilla – Full Text Bug Listing
|Summary:||System cycles immediately back to sleep after resume|
|Product:||[Fedora] Fedora||Reporter:||Noel J. Bergman <noel>|
|Component:||gnome-power-manager||Assignee:||Richard Hughes <richard>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||adam, ceski, davidp, dexterthrowaway, graziani, greg_orlowski, jbk, jensk.maps, jeremy, jesse.brandeburg, kernel-maint, leo, lostlake, mail, mkreder, neumann, pastashapes, p, phalenor, redhat, rhn, rhughes, richard, rzhou, samtygier, sassmann, steven.chapel, tore|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-06-25 10:20:03 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Noel J. Bergman 2008-12-09 13:05:37 EST
I thought that I had reported this before, but I cannot find the bug in bugzilla anymore, so ... Description of problem: Host: Thinkpad T61p 6457-7WU OS: Fedora 10 with all updates applied as of date of report. Suspend-To-RAM works. Resume from suspend works. HOWEVER, the first few times I wake up the the laptop, it flashes some text on the screen and immediately goes back to sleep. Somewhere in the 2nd to 4th time it will, instead, properly display the background and gnome-screensaver-dialog for me to unlock the screen. It is behaving as if in some form of race condition it had not clear the fact that it has the sleep event. Version-Release number of selected component (if applicable): Kernel: 184.108.40.206-117.fc10.x86_64 How reproducible: Very. Steps to Reproduce: See description. Actual results: Computer requires multiple wake cycles to wake. Expected results: Computer should come back the first time, and not sleep again.
Comment 1 Noel J. Bergman 2008-12-09 18:11:47 EST
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
Comment 2 Noel J. Bergman 2008-12-09 18:13:06 EST
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
Comment 3 Noel J. Bergman 2008-12-09 18:16:14 EST
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.
Comment 4 Noel J. Bergman 2008-12-09 18:33:26 EST
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.
Comment 5 Noel J. Bergman 2008-12-09 18:41:59 EST
Found another, similar, bug in upstream, although my scenario has nothing to do with hibernate; mine is purely suspend-to-RAM and resume based.
Comment 6 Greg Orlowski 2008-12-09 18:56:06 EST
I get the same behavior. $ uname -a Linux ... 220.127.116.11-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?
Comment 7 Greg Orlowski 2008-12-09 18:57:16 EST
Created attachment 326433 [details] relevant section from my /var/log/messages, showing repeated suspend+resume cycle
Comment 8 Noel J. Bergman 2008-12-10 13:03:59 EST
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.
Comment 9 Tim Pepper 2009-02-10 18:09:10 EST
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.
Comment 10 Ricky Zhou 2009-02-17 23:54:56 EST
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.
Comment 11 AEsberger 2009-02-18 19:19:43 EST
I can confirm same behavior on a Samsung Q310.
Comment 12 Phil Knirsch 2009-02-19 09:14:45 EST
*** Bug 465192 has been marked as a duplicate of this bug. ***
Comment 13 Matías Kreder 2009-02-19 13:38:45 EST
I'm not experiencing this problem with latest kernel: kernel-18.104.22.168-170.2.24.fc10.i686 Linux perla 22.214.171.124-170.2.24.fc10.i686 #1 SMP Wed Feb 11 23:58:12 EST 2009 i686 i686 i386 GNU/Linux
Comment 14 Tim Pepper 2009-02-19 14:39:32 EST
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-126.96.36.199-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 <firstname.lastname@example.org> - 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.
Comment 15 Nicholas LaRoche 2009-02-24 10:19:41 EST
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.
Comment 16 Giacomo Graziani 2009-02-25 09:41:56 EST
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-188.8.131.52-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.
Comment 17 Tim Pepper 2009-02-25 17:29:35 EST
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.
Comment 18 dexterthrowaway 2009-06-22 06:16:31 EDT
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.
Comment 19 dexterthrowaway 2009-06-23 23:14:08 EDT
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.
Comment 20 James 2009-07-11 05:09:48 EDT
(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.)
Comment 21 Davide Cescato 2009-07-21 17:07:18 EDT
Confirmed on a fully updated F11 with gnome-power-manager-2.26.3-1.fc11.x86_64, installed on a Lenovo Thinkpad W500.
Comment 22 Felix Möller 2009-07-26 03:21:12 EDT
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?
Comment 23 Pádraig Brady 2009-07-29 08:40:39 EDT
Me too. Never happened on Fedora 8. Happens now on 184.108.40.206-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.
Comment 24 Richard Körber 2009-07-29 09:09:41 EDT
*** Bug 495993 has been marked as a duplicate of this bug. ***
Comment 25 Jesse Brandeburg 2009-08-12 01:39:56 EDT
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.
Comment 26 Andy Cobaugh 2009-08-14 23:20:35 EDT
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 220.127.116.11-217.2.3.fc11.i686.PAE gnome-power-manager-2.26.3-1.fc11.i586 xorg-x11-server-Xorg-18.104.22.1681-1.fc11.i586
Comment 27 Richard Hughes 2009-08-20 07:35:48 EDT
Still happens with F11?
Comment 28 Sam Tygier 2009-08-20 07:55:05 EDT
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.
Comment 29 Pádraig Brady 2009-08-20 08:08:29 EDT
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 22.214.171.124-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.
Comment 30 Richard Körber 2009-08-20 08:30:13 EDT
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...
Comment 31 Andy Cobaugh 2009-08-20 09:56:06 EDT
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.
Comment 32 Walter Neumann 2009-08-20 20:43:47 EDT
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 126.96.36.199-25.fc11.i586 It happens consistently if I suspend with function key, and occasionally if I suspend by closing lid.
Comment 33 James 2009-10-27 14:20:01 EDT
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
Comment 34 Kelly-Rand 2009-11-15 11:33:30 EST
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
Comment 35 Bug Zapper 2009-11-18 05:24:46 EST
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
Comment 36 Tore Anderson 2009-11-22 00:00:43 EST
I believe I'm seeing this bug in Fedora 12. I also think bugs #197007 and #529487 are duplicates of this one. Tore
Comment 37 Bug Zapper 2009-12-18 02:13:47 EST
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.
Comment 38 Pádraig Brady 2009-12-18 04:31:22 EST
I'm seeing this on F11. I've not seen a specific fix mentioned. Also others have mentioned it's still present in F12.
Comment 39 Adam Goode 2009-12-30 17:54:44 EST
I am seeing this today on F12.
Comment 40 Adam Goode 2010-01-05 22:17:42 EST
This happens if I suspend while plugged in, and resume after unplugging the power cord. I assume the unplug event is queuing up?
Comment 41 Jesse Brandeburg 2010-01-27 18:54:27 EST
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.
Comment 42 Jeremy Fitzhardinge 2010-01-27 19:10:06 EST
(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.
Comment 43 Pádraig Brady 2010-01-27 19:32:01 EST
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.
Comment 44 Sam Tygier 2010-01-28 05:55:33 EST
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 < email@example.com> Thu, 28 Jan 2010 08:26:09 +0800
Comment 46 Sam Tygier 2010-01-28 07:04:09 EST
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 < firstname.lastname@example.org> Wed, 27 Jan 2010 02:02:00 +0800
Comment 47 Walter Neumann 2010-02-22 03:21:49 EST
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".
Comment 48 Richard Hughes 2010-03-03 04:36:40 EST
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.
Comment 49 Jens Knutson 2010-04-18 03:58:36 EDT
I'm running F13 alpha with updates current as of today, and I am still seeing this problem.
Comment 50 Walter Neumann 2010-04-18 08:17:35 EDT
Jens: did you try the solution in comment 47? It has completely solved it for me.
Comment 51 Jens Knutson 2010-04-18 14:04:27 EDT
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.
Comment 52 Jens Knutson 2010-05-26 20:17:46 EDT
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.
Comment 53 Steve Chapel 2010-07-13 22:55:04 EDT
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.
Comment 54 Bug Zapper 2010-11-04 07:37:36 EDT
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
Comment 55 Pádraig Brady 2010-12-04 18:03:56 EST
This is definitely fixed for me in F14
Comment 56 Bug Zapper 2011-06-02 14:20:58 EDT
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
Comment 57 Steve Chapel 2011-06-12 18:31:26 EDT
This issue is also fixed for me in Fedora 14.