Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Resume immediately suspends again on Thinkpad X200|
|Product:||[Fedora] Fedora||Reporter:||Jeremy Fitzhardinge <jeremy>|
|Component:||pm-utils||Assignee:||Phil Knirsch <pknirsch>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||bos, chrb, etienne.lequeux, hedayatv, karlcz, kwade, mkarg, opensource, petrosyan, pknirsch, richard, rvokal|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-02-19 09:14:45 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jeremy Fitzhardinge 2008-10-01 20:44:35 EDT
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:
Comment 1 petrosyan 2008-10-01 22:22:20 EDT
Exactly the same thing happens on Thinkpad X61.
Comment 2 Till Maas 2008-10-02 13:36:03 EDT
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?
Comment 3 Jeremy Fitzhardinge 2008-10-02 15:01:02 EDT
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.
Comment 4 Bryan O'Sullivan 2008-10-12 22:10:49 EDT
Comment 5 Bryan O'Sullivan 2008-10-12 22:11:39 EDT
Maybe Jeremy means Fn-F4 - it's the thinkpad's "suspend" button.
Comment 6 Jeremy Fitzhardinge 2008-10-12 22:27:27 EDT
Right. F5 is wireless toggle.
Comment 7 Need Real Name 2008-11-05 20:50:20 EST
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.
Comment 8 Jeremy Fitzhardinge 2008-11-06 04:34:12 EST
It does seem to be specific to using a hotkey. Using the "System->Power down" menu or a pm-* command resumes properly.
Comment 9 Bug Zapper 2008-11-25 22:26:35 EST
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
Comment 10 Hedayat Vatankhah 2008-12-07 13:09:56 EST
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 )
Comment 11 Karsten Wade 2008-12-09 06:58:29 EST
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.
Comment 12 Karsten Wade 2008-12-09 06:59:44 EST
Created attachment 326288 [details] Log file showing pm-utils activity around re-suspend event.
Comment 13 Phil Knirsch 2008-12-09 08:26:54 EST
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
Comment 14 Karsten Wade 2008-12-09 12:38:00 EST
(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.
Comment 15 Till Maas 2008-12-09 13:21:22 EST
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.