Bug 1249363 - Unable to suspend more than once with 4.1.x kernels with lid close on thinkpad w520 [NEEDINFO]
Summary: Unable to suspend more than once with 4.1.x kernels with lid close on thinkpa...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-08-02 00:53 UTC by Andy Wang
Modified: 2015-11-23 17:17 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-23 17:17:47 UTC
Type: Bug
jforbes: needinfo?

Attachments (Terms of Use)

Description Andy Wang 2015-08-02 00:53:53 UTC
Description of problem:
Unable to suspend with 4.1.x kernels more than one time when using lid close.  I can suspend once, but additional attempts fail.  This is on a thinkpad w520 using intel graphics.
Also, suspend works with the power button.

Version-Release number of selected component (if applicable):

How reproducible:
Closing alid a seocnd time, and all subsequent times will not suspend.

Steps to Reproduce:
1. start with a fresh boot to gdm (or logged into gnome)
2. close the lid - suspends
3. open the lid - wakes up laptop
4. close the lid again - will not suspend

Additional info:
The following kernel message occurs.  I don't know if this is related:
[ 1603.289614] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment

Comment 1 Andy Wang 2015-08-02 00:54:42 UTC
I reported this against kernel because booting kernel-4.0.8-300.fc22.x86_64 works fine.

Comment 2 Ben Sebastian 2015-08-03 03:30:33 UTC
I can confirm this bug on a T440s with Intel Graphics. The laptop fails to suspend most times the lid is closed, when the issue occurs the following message appears in the journal 

i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment 

This also seems to prevent the external display from being activated when the laptop is resumed from suspend when docked in the Lenovo Ultra Dock.

Comment 3 zingale 2015-08-03 09:57:15 UTC
I have the same issue with a T440s.  Things work fine with 4.0.8-300.fc22, but fail with vmlinuz-4.1.2-200.fc22 and vmlinuz-4.1.3-200

Comment 4 Andy Wang 2015-08-03 13:38:18 UTC
One thing I noticed in my testing is that if I try to suspend immediately after booting to 4.0.8-300 it doesn't suspend. I get the same i915 message.

But after some period of time (i haven't figured out how long) it will suspend and continue to suspend without problem.  I just noticed this in testing as I don't normally suspend immediately after a reboot.

Comment 5 Adam Chasen 2015-08-03 14:55:04 UTC
I am seeing similar suspend once behavior on a Thinkpad Carbon X1. I do see the logind service recognize the close/open behavior but suspend only occurs on the first close. Possibly a bug in docking detection logic?

Comment 6 Adam Chasen 2015-08-03 15:40:04 UTC
Seems to duplicate bug 1244435 which indicated that the kernel version may not be the culprit.

Comment 7 zingale 2015-08-03 15:56:43 UTC
I just looked at that bug, and they probably are related somehow, but for me, I have no suspect issues with 4.0.8.  I rebooted to that earlier in the day and have suspended and resumed many times since without issue, so for me, dropping down to an earlier kernel makes the problem go away.

Comment 8 Adam Chasen 2015-08-05 16:28:03 UTC
Using 4.0.8-200.fc21.x86_64 did not resolve the issue for me. I was able to get consistent suspend/resumes on one boot with 4.1.2-200.fc22.x86_64 once, but after rebooting I saw the same behavior. Either way logs show the system is capturing the lid close/open events which makes me thing it is not the kernel, but something else.

Comment 9 Tom Johnson 2015-08-09 10:03:52 UTC
4.0.8-300 makes no difference to me; I also have the problem with 4.1.3-201. I'm using systemd 219 on a Fujitsu Lifebook AH532. For the 4.1.3-201 kernel, I managed to get a successful suspend followed by a failure, logs at http://pastebin.com/7gvp879e.

Comment 10 Mikkel Lauritsen 2015-08-13 08:56:54 UTC
Same here on a Clevo W550EU - first suspend after reboot works, all subsequent attempts to suspend by closing the lid do not. The problem has appeared some time after I upgraded to F22 as repeated suspends initially worked fine.

The first time /var/log/messages contains entries like

Aug 11 15:27:39 laptop systemd-logind: Lid closed.
Aug 11 15:27:39 laptop systemd-logind: Suspending...
Aug 11 15:27:39 laptop NetworkManager[902]: <info>  sleep requested (sleeping: no  enabled: yes)
Aug 11 15:27:39 laptop NetworkManager[902]: <info>  sleeping...
Aug 11 15:27:39 laptop NetworkManager[902]: <info>  (wlp2s0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37]
Aug 11 15:27:39 laptop NetworkManager[902]: <info>  (wlp2s0): deactivating device (reason 'sleeping') [37]

whereas the following attempts only contain

Aug 12 16:17:10 laptop systemd-logind: Lid closed.
Aug 12 16:17:20 laptop systemd-logind: Lid opened.

- in that case I apparently gave up waiting for something to happen after 10 seconds :-)

It seems as if systemd-logind is somehow to blame since the "Suspending..." line is missing from the log?

Comment 11 Andy Wang 2015-08-13 16:13:24 UTC
Problem appears to have gone away with kernel-4.1.4-200.fc22.x86_64.  At least on my Thinkpad W520.

Comment 12 Mikkel Lauritsen 2015-08-14 06:23:14 UTC
Seems to work here as well. I basically just installed the last updates but no other updated packages than the kernel would appear to have any influence on suspend/resume.

Comment 13 David H. Gutteridge 2015-09-04 21:24:22 UTC
This may be related to bug 1249822, which is a systemd issue. There is an updated version of systemd in testing which is supposed to address that bug report. (https://bodhi.fedoraproject.org/updates/systemd-219-23.fc22)

Comment 14 Justin M. Forbes 2015-10-20 19:30:47 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.

Comment 15 Fedora Kernel Team 2015-11-23 17:17:47 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

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