Description of problem: When resuming from suspend to ram, the system immediately suspends again. Resuming a second time works OK. Version-Release number of selected component (if applicable): pm-utils-1.2.0-1.fc10.x86_64 How reproducible: Always Steps to Reproduce: 1.Suspend machine 2.Resume 3. Actual results: Suspends again Expected results: Full resumption Additional info:
Exactly the same thing happens on Thinkpad X61.
petrosyan: Why did you change the status to ASSIGNED? Do you know what to fix and are you working on it? Imho triage is not yet done, because it is not clear which component needs to be fixed (can be pm-utils, kernel, gnome-power-manager, ...). Jeremy: In case petrosyan is not working on this bug, I guess we need more information. How do you suspend? Which kernel do you use?
I'm using kernel 2.6.27-0.377.rc8.git1.fc10.x86_64 I suspend with Fn-F5; lidswitch doesn't seem to work. I resume with either opening the lid, pushing power, or pushing Fn. The behaviour is the same in all cases.
<metoo/>
Maybe Jeremy means Fn-F4 - it's the thinkpad's "suspend" button.
Right. F5 is wireless toggle.
I am seeing this with hibernate via Fn-12 as well on my X200 using the 10-Preview release, using the vesa driver since the intel driver hangs. Also, with Fn-12 I see a screen unlock prompt briefly before it starts hibernating again. FWIW, it does not occur if I echo "disk" to /sys/power/state. With this method, it resumes with an unlocked screen.
It does seem to be specific to using a hotkey. Using the "System->Power down" menu or a pm-* command resumes properly.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I've the same problem too. (X61, suspends again (2 or 3 times) when using Fn+F4 keys, but not when using suspend menu entry )
I'll call with a "me too" for a T60, i915 Intel video, and I'll raise with my latest pm-suspend.log that shows this event happening in the middle. (Attached following.) I've only ever used the keys to suspend, so this has been happening to me since I upgraded to Fedora 10. All packages updated as of today.
Created attachment 326288 [details] Log file showing pm-utils activity around re-suspend event.
As mentioned already in other comments this is almost guaranteed not a problem with the tools in pm-utils itself but rather one of the GUI tools that call the pm-utils tools. We've seen the same thing happening here as well occasionally, and one possible cause would be (though we haven't been able to verify that yet) is that upon wakeup the GUI doesn't get notified properly any more that the system was just woken up and assumes that it has been idle for X hours on battery power upon which it will immediately automatically suspend the machine again. We sometimes could prevent the "resuspend" when we hammered one of the keys, e.g. spacebar so that the GUI noted that the system was actually not idle. But as i said, this is just a suspicion we have so far. The other reason could be that the suspend hotkey is for some odd reason still queued/pressed, so after wakeup the system immediately gets that notification and suspends again, but this would also sound more of a driver problem than a problem of pm-utils. As we don't have a lot more info i'm reluctant to reassign this bug to another component though. So if anyone who has that problem could investigate it a bit further that would be awesome. Recently we haven't been able to reproduce it here any more, so it's a bit tricky for us to debug it. Thanks & regards, Phil
(In reply to comment #13) > We've seen the same thing happening here as well occasionally, and one possible > cause would be (though we haven't been able to verify that yet) is that upon > wakeup the GUI doesn't get notified properly any more that the system was just > woken up and assumes that it has been idle for X hours on battery power upon > which it will immediately automatically suspend the machine again. > > We sometimes could prevent the "resuspend" when we hammered one of the keys, > e.g. spacebar so that the GUI noted that the system was actually not idle. This is actually familiar with parts of my experienced. Sometimes it takes two or three unsuspend calls to wake-up, with a pattern like this: * Shows wakeup then sleep again, all with no graphics shown * Shows screensaver login dialog briefly, then sleeps * Finally wakes up, shows the screensaver login, but does not accept key/mouse input for several seconds In the final case, it always stays awake at that point. It's almost as if taking several attempts to move from "must sleep" to "must awake." > As we don't have a lot more info i'm reluctant to reassign this bug to another > component though. So if anyone who has that problem could investigate it a bit > further that would be awesome. Recently we haven't been able to reproduce it > here any more, so it's a bit tricky for us to debug it. I'm glad to keep trying anything. So far, here are some things I see to try: * Without changing anything from what I've been doing, add the step of hammering shift or spacebar to force a wake-up. * Turn off the screensaver (and it's screen lock) before suspending, see if that changes anything. Since you don't think it's pm-utils, it doesn't make sense to run it under strace, right? But perhaps if we suspect something else, such as screensaver, then maybe I can try that with strace.
Maybe it helps to look at the acpid log output (probably in /var/log/messages). But afaik the keys are nowadays handled somehow by hal, therefore it would also nice to monitor dbus. But I do not know, how.
This looks like a dupe of bug #475585
Yea, true as it works with the commandline tool but not with the function keys. Closing it as a dup of that one then. Thanks & regards, Phil *** This bug has been marked as a duplicate of bug 475585 ***