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): kernel-4.1.2-200.fc22.x86_64 kernel-4.1.3-200.fc22.x86_64 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
I reported this against kernel because booting kernel-4.0.8-300.fc22.x86_64 works fine.
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.
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
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.
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?
Seems to duplicate bug 1244435 which indicated that the kernel version may not be the culprit.
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.
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.
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.
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?
Problem appears to have gone away with kernel-4.1.4-200.fc22.x86_64. At least on my Thinkpad W520.
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.
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)
*********** 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.
*********** 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.