Bug 1161943 - Thinkpad x240 cannot resume from suspend
Summary: Thinkpad x240 cannot resume from suspend
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-09 16:06 UTC by Andy Lindeberg
Modified: 2015-03-27 16:07 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-10 14:42:36 UTC


Attachments (Terms of Use)

Description Andy Lindeberg 2014-11-09 16:06:00 UTC
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.

Comment 1 Valent Turkovic 2014-11-12 18:19:29 UTC
Are you using luksCrypt?

Comment 2 Marc Ponschab 2014-11-15 11:54:16 UTC
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?

Comment 3 Andy Lindeberg 2014-11-17 16:12:47 UTC
(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.

Comment 4 Valent Turkovic 2014-11-17 22:06:47 UTC
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.

Comment 5 Peter Thorstenson 2014-11-18 22:38:19 UTC
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.

Comment 6 Josh Boyer 2014-11-18 23:28:05 UTC
Suspend on lid close is probably a DE or systemd issue.

Comment 7 Peter Thorstenson 2014-11-19 08:02:00 UTC
(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.

Comment 8 Samuel Sieb 2014-11-20 06:18:19 UTC
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.

Comment 9 Samuel Sieb 2014-11-20 06:19:41 UTC
And if there is a problem, please open a new bug as that's completely different from this one.

Comment 10 Peter Thorstenson 2014-11-20 07:49:59 UTC
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
...
...
------------------------------------------------------------------------

Comment 11 Samuel Sieb 2014-11-20 08:02:07 UTC
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.

Comment 12 Peter Thorstenson 2014-11-20 08:04:17 UTC
(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.

Comment 13 Valent Turkovic 2015-02-09 20:23:01 UTC
I believe this bug has been resolved, on my Lenovo T440s suspend and resume work as expected on Fedora 21 with all latest updates.

Comment 14 Josh Boyer 2015-02-10 14:42:36 UTC
Thank you.


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