Fedora 18 suspends again on first resume

[benwaugh]

This is not 100% reproducible, but occurs at least half the time.

I am using Fedora 18 on my laptop (HP EliteBook 2540p) with the MATE window manager. After installing lightdm to replace gdm, I can set my laptop to suspend when the lid is closed. However, when I resume by opening it and pressing the power button, it often wakes only briefly (a few seconds) and then suspends again. On the second resume all is OK again.

Any ideas? Is it possible there are two separate mechanisms trying to handle the suspend, so that the slower one completes only after the faster one has suspended the machine the first time and the machine has then resumed. Just guessing at the moment.

[george_toolan]

I don't know about MATE and lightdm, but with Gnome you just have to open the lid to resume.

If you open the lid and press the power button you'll probably send it back to sleep again ;-)

[benwaugh]

Depends on the laptop. My previous laptop (a Toshiba) resumed when the lid was opened, but this one has always needed the power button to be pressed. Up to Fedora 17 it worked fine, but admittedly that was with XFCE and gdm rather than MATE and lightdm.

[StephenH]

Check to see if your power manager and screensaver are both set to lock the screen. Once I unchecked that option in xfce4-power-manager-settings, the immediate suspend ceased. Now I only have the option to lock in xscreensaver. Of course, I could also have uninstalled xscreensaver and left the lock function active in xfce4-power-manager instead, but I didn't.

[benwaugh]

Thanks for the suggestion. Interesting that you had a similar problem and solved it. It seems the MATE power manager doesn't have a "lock screen" option though, and switching back to XFCE and unchecking the "lock screen" option in the power manager doesn't fix this for me.

[crxssi]

I am having the same problem.

On Fedora 17 KDE on my Lenovo Thinkpad Twist, I never had any suspend (to RAM) problems. But under 18 KDE, it seems like half the time when I open the screen to resume from a suspend/sleep, the screen comes on for a few seconds, and then it re-suspends! I have to either close the top and reopen it again or press the power button. When it comes out of suspend the second time, it always stays un-suspended.

Has nothing to do with lock screensaver (which I have always had off). Otherwise it works well- restores quickly, X11/WiFi/sound/etc all come back each time.

Of course, right before I wrote this, there was yet another kernel update (3.7.7) and it is not doing it the several times I tested while I am writing this posting.

[benwaugh]

I still have this problem despite upgrading to kernel 3.7.7-201.fc18.x86_64. Since a few days after my initial report, it has been doing this consistently every time I suspend and resume.

[David Batson]

I don't think this is a kernel issue. Had this problem in the past. Here is how I resolved it then.

http://forums.fedoraforum.org/showthread.php?t=228242

[crxssi]

I don't think this is a kernel issue. Had this problem in the past. Here is how I resolved it then.

http://forums.fedoraforum.org/showthread.php?t=228242

What is your theory of operation for unassigning two keys with xmodmap? In my particular case, I am closing and opening the lid, without ever pressing any keys (although maybe the lid is sending keycodes?)

If it starts doing it again, I will try your fix. Thanks

[David Batson]

I think that one suspension script was triggered by the acpi event, and a second script was triggered by the XF86Sleep keysym. Basically, I believe I had two suspend scripts loaded by a couple of different power managers. PM-Utils is one, Gnome Power Manager another, Tux on Ice another...

[amarino]

Hi to everybody,
I've got the same problem with my laptop (an Acer Aspire 2930, F18 64 bit); I've configured the power button event to suspend-on-RAM the PC, so I usually stop it in this way, leaving the lid almost always open; in a not reproducible way the PC requires more than one resumes, more frequently these last days.
I've noticed that the problem is bigger as the pc has been turned on (or even suspended) longer: I've just suspended it now, while reading your posts, after a couple of hours of usage, and it requested 3 resumes to work properly; obviously I tried to suspend it again immediately after and... ok, now it resumes normally.
Could it be a sort of timing-related problem? I intend that after a certain time of usage or of suspend status, the PC understands that it must suspend again, even if I've just resumed it. Notice that I've already deactivated all "suspend after x minutes" options in the power management window, but... maybe?

[David Batson]

I haven't used suspend in awhile in Arch, but just ran into this issue there. As I posted above, the solution was to find the offending keysym and remove it, as acpi handles this already.

[david@myhost ~]$ xmodmap -pke | grep XF86Sleep
keycode 150 = XF86Sleep NoSymbol XF86Sleep

[david@myhost ~]$ gedit .Xmodmap

Added the following line to /home/~/.Xmodmap

keycode 150 =

Ran xmodmap .Xmodmap

[david@myhost ~]$ xmodmap .Xmodmap
[david@myhost ~]$ xmodmap -pke | grep XF86Sleep
[david@myhost ~]$

Problem solved.

[amarino]

Thanks David, but I already tested your trick and it doesn't work on my laptop; now it is set just as you suggest and the problem still persists. Can you tell me if I have to modify your instructions to refer them to the power-on button, that I normally use to suspend-on-RAM my PC?
In the meanwhile I've noticed how to reproduce the problem: after about one hour of normal usage (internet, movie or music, etc), if I suspend the laptop it requires to be resumed twice; after about two-three hours of normal usage, if I suspend the laptop it requires to be resumed three times.

[StephenH]

David,

Your solution appears to have mixed results here. On my Acer Aspire One 722 with AMD C50 processor, it appears to have solved the problem. However, on my wife's Acer Aspire One D250 with Intel Atom processor, it has not. I would rather it had been the other way around as I can put up with the glitch for now. However, she is after me to get this fixed and NOW!

I'll have to see what else is different between the two machines in settings that would cause the different outcome.

[gesser]

I've fixed this problem on my laptop (Fedora 18, Dell Studio 1535)

1. Edit /etc/systemd/logind.conf file (of course, you must have root privileges);
2. Uncomment "HandleLidSwitch" parameter and change it's value to "ignore".

the result file should look like this:

cat /etc/systemd/logind.conf

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# See logind.conf(5) for details

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#Controllers=
#ResetControllers=cpu
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min

restart systemd-logind.service:

systemctl restart systemd-logind.service

More information: https://wiki.archlinux.org/index.php...wer_management

Cheers!