Hide Forgot
My laptop occasionally stops suspending when I close the lid. That is, it normally works fine - but once in a while, it starts ignoring lid events. Once it gets into that state, it stays that way until I reboot it. I don't actually know how to debut this problem. The output of "dmesg" shows no attempt to suspend. (See the lines starting at "[Jul29 06:28]"; you can see the events for USB and ethernet being unplugged - just before I closed the lid - but nothing about suspending).
Created attachment 1058898 [details] dmesg
This is a duplicate of #1174480. I'm leaving it open as a clone for Fedora 22.
I can confirm this exactly behavior on a Lenovo ThinkPad T440s, with all patches installed as of 05-Aug-2015 and the following configuration: BIOS Information Vendor: LENOVO Version: GJET82WW (2.32 ) Release Date: 01/09/2015 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 16384 kB Characteristics: PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 2.32 Firmware Revision: 1.9 When the lid closes I see the following message on dmesg: [77781.703883] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
(In reply to Antonio Dias from comment #3) > > [77781.703883] i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has > bogus alignment This error is an Intel PCI resource mess in the kernel that has re-surfaced. You should be able to reproduce this error msg by simply doing "echo 1 > /sys/bus/pci/rescan" You should try a newer or older kernel and see if this is triggered as well as to see if suspend starts working again.
I have the same issue, which started rather recently (about a week or two), and I see this i915 error message back from when I installed F22 when it was still in beta. I don't think that is the problem. I've enabled debug logging for logind, and I see this in the log: Aug 07 10:21:58 jior systemd-logind[847]: Lid closed. Aug 07 10:21:58 jior systemd-logind[847]: Multiple (4) displays connected. Aug 07 10:21:58 jior systemd-logind[847]: Refusing operation, as it is turned off. Aug 07 10:21:58 jior systemd-logind[847]: Multiple (4) displays connected. Aug 07 10:21:58 jior systemd-logind[847]: Refusing operation, as it is turned off. My system is a Dell E5440 with this lspci output: 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b) 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) ... 02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73) 03:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] (rev ff)
Created attachment 1060306 [details] Suggested patch that solves my problem This patch against systemd solved my problem: From looking at udev output, there are several available display connections whose status is "unknown" (so says udev). The logind-core code counts any not "disconnected" display as connected and preventing suspend (i.e. if there is more than one). My patch also discounts any "unknown" state displays, and now my laptop suspends fine when undocked and does not suspend when docked.
One more piece of info: I've started pressing the "Power" button before closing the lid, just to ensure the laptop is actually suspended. Right now, when I do that, the laptop suspends - then immediately wakes up. It's possible that this is what has been happening all along - though I haven't confirmed it. Of course, I don't know what's causing it to wake up.
http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f22&id=bac6df9d13c051c20c51b7eb6caa7688fa4b20dd
The above patch works for me - with that systemd I no longer have problems with automatic suspend.
Does not work here see: https://bugzilla.redhat.com/show_bug.cgi?id=1244435#c15
bug #1244435 doesn't seem related to the monitor count issue in systemd.
The systemd-219-23 update seems to have fixed it for me, but is there a reason that update was not linked to this bug report?
I have no idea. The new bodhi simply didn't link the bugs. Fixed by https://bodhi.fedoraproject.org/updates/systemd-219-23.fc22