Bug 465192 - Resume immediately suspends again on Thinkpad X200
Summary: Resume immediately suspends again on Thinkpad X200
Keywords:
Status: CLOSED DUPLICATE of bug 475585
Alias: None
Product: Fedora
Classification: Fedora
Component: pm-utils
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-02 00:44 UTC by Jeremy Fitzhardinge
Modified: 2015-03-05 01:20 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-19 14:14:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Log file showing pm-utils activity around re-suspend event. (5.98 KB, text/plain)
2008-12-09 11:59 UTC, Karsten Wade
no flags Details

Description Jeremy Fitzhardinge 2008-10-02 00:44:35 UTC
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-02 02:22:20 UTC
Exactly the same thing happens on Thinkpad X61.

Comment 2 Till Maas 2008-10-02 17:36:03 UTC
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 19:01:02 UTC
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-13 02:10:49 UTC
<metoo/>

Comment 5 Bryan O'Sullivan 2008-10-13 02:11:39 UTC
Maybe Jeremy means Fn-F4 - it's the thinkpad's "suspend" button.

Comment 6 Jeremy Fitzhardinge 2008-10-13 02:27:27 UTC
Right.  F5 is wireless toggle.

Comment 7 Need Real Name 2008-11-06 01:50:20 UTC
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 09:34:12 UTC
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-26 03:26:35 UTC
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 18:09:56 UTC
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 11:58:29 UTC
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 11:59:44 UTC
Created attachment 326288 [details]
Log file showing pm-utils activity around re-suspend event.

Comment 13 Phil Knirsch 2008-12-09 13:26:54 UTC
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 17:38:00 UTC
(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 18:21:22 UTC
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.

Comment 16 chrb 2009-02-02 13:24:49 UTC
This looks like a dupe of bug #475585

Comment 17 Phil Knirsch 2009-02-19 14:14:45 UTC
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 ***


Note You need to log in before you can comment on or make changes to this bug.