Description of problem: As per title, Thinkpad x240 running F21 will not resume from suspend, but requires a hard restart. How reproducible: Happens every time Steps to Reproduce: 1. Suspend system via any method (close lid, press power button, press alt-power under the battery menu, run pm-suspend) Actual results: Laptop enters sleep successfully, but becomes unresponsive. Opening lid, pressing power button, using mousepad/trackpoint, and pressing keys are all ignored. Only option to regain function is to hold down power button and force a restart. Expected results: Laptop wakes up from sleep appropriately. Additional info: Based on some searches for similar problems, I have tried the following: 1) Adding "resume=/dev/dm-1" to grub. No result. 2) Turning automatic screen lock off. No result. I have also tried testing pm-hibernate and pm-suspend-hybrid to see if they exhibit similar behavior. They do not. Instead, they exhibit no behavior whatsoever.
Are you using luksCrypt?
I have the same problem on an Asus N76VM, up-to-date F21. LVM is on top of an luks encrypted partition: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465,8G 0 disk ├─sda1 8:1 0 200M 0 part /boot/efi ├─sda2 8:2 0 500M 0 part /boot └─sda3 8:3 0 465,1G 0 part └─luks-117579e6-5c99-4ec1-ae69-06d4135c44cb 253:0 0 465,1G 0 crypt ├─fedora_n38-root 253:1 0 68,4G 0 lvm / ├─fedora_n38-swap 253:2 0 7,8G 0 lvm [SWAP] ├─fedora_n38-home 253:3 0 244,1G 0 lvm /home ├─fedora_n38-LV_NODE1 253:4 0 20G 0 lvm ├─fedora_n38-LV_NODE2 253:5 0 20G 0 lvm ├─fedora_n38-LV_NODE3 253:6 0 5G 0 lvm ├─fedora_n38-LV_W7 253:7 0 40G 0 lvm ├─fedora_n38-LV_W8 253:8 0 30G 0 lvm └─fedora_n38-LV_iKSPEE 253:9 0 20G 0 lvm sr0 11:0 1 1024M 0 rom On resume the device locks up completly, pressing the caps lock key does nothing. Network seems also down (no respond when pinging). Any useful information i can provide? Should i open another bug, since the hardware differs?
(In reply to Valent Turkovic from comment #1) > Are you using luksCrypt? Originally yes, it was an encrypted install. Problem persisted when I tried a LiveUSB and an unencrypted install, though. Problem is resolved if I install F20, both encrypted and unencrypted.
I tried using "debugging" kernel in GRUB menu on my Lenovo T440s, and bingo! Now suspend/resume works every time in every as expected! It is interesting that suspend/resume works it is a bit slower to suspend with "debugging" kernel. On "normal" kernel suspend is instant, when I enter "pm-suspend" or press suspend via GUI screen just goes black right away. With "debugging" kernel when I issue suspend command first I see lock screen, then screen goes black, then it blinks once more with lock screen and then it goes off. Please also try choosing "debugging" kernel on your laptop and report back.
I have an X240 with the same problem. At least it used to be the same problem. Now after the lastest update (Kernel 3.17.3-300 and some other stuff), the machine does not even go to suspend when I close the lid. It stays on. If I do "systemctl suspend", it suspends and but then it doesn't resume. I tried kernels 3.17.2-300 and 3.17.1-302 but the problem remains the same strangely enough. After I disabled the TPM in the BIOS, it now resumes when I open the lid, but it still doesn't suspend when I close it.
Suspend on lid close is probably a DE or systemd issue.
(In reply to Josh Boyer from comment #6) > Suspend on lid close is probably a DE or systemd issue. That might be so. I was a bit hasty when I said it doesn't suspend when closing the lid--it does 3 out of 10 times. I double boot with Debian Jessie XFCE4 and there I have exactly the same symptoms except Jessie suspends 5 times out of 10... Jessie Mate acted the same way which is why I gave up on it. My hope lays with Fedora.
Install "evtest" and open a terminal as root. Look in /proc/bus/input/devices for the lid switch device. There should be a line containing something like "H: Handlers=event1". Run "evtest /dev/input/event1". (Replace event1 with the handler value.) Close the lid and open it. You should get an event for both actions. If you get the events and the laptop doesn't suspend, then there's a problem, probably with systemd as that's what handles the lid switch by default now.
And if there is a problem, please open a new bug as that's completely different from this one.
Thanks. Very neat. This is what I got--a looong series of 1's followed by 0's. I suppose that indicates that the lid switch is working. Just wanted to check that that's the case before I file a new bug report. ----------------------------------------------------------------------- # evtest /dev/input/event0 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x0 product 0x5 version 0x0 Input device name: "Lid Switch" Supported events: Event type 0 (EV_SYN) Event type 5 (EV_SW) Event code 0 (SW_LID) Properties: Testing ... (interrupt to exit) Event: time 1416467979.950168, type 5 (EV_SW), code 0 (SW_LID), value 1 Event: time 1416467979.950168, -------------- SYN_REPORT ------------ Event: time 1416467987.088439, type 5 (EV_SW), code 0 (SW_LID), value 0 Event: time 1416467987.088439, -------------- SYN_REPORT ------------ Event: time 1416468009.078878, type 5 (EV_SW), code 0 (SW_LID), value 1 Event: time 1416468009.078878, -------------- SYN_REPORT ------------ Event: time 1416468012.220144, type 5 (EV_SW), code 0 (SW_LID), value 0 ... ... ------------------------------------------------------------------------
Yes, if you get one of those pairs each time you close and open the lid, then the lid switch is working and the kernel is getting the messages.
(In reply to Samuel Sieb from comment #11) > Yes, if you get one of those pairs each time you close and open the lid, > then the lid switch is working and the kernel is getting the messages. Thank you for verifying that. I will file a new bug report later today.
I believe this bug has been resolved, on my Lenovo T440s suspend and resume work as expected on Fedora 21 with all latest updates.
Thank you.