Bug 1249822 - Laptop sometimes doesn't suspend when the lid is closed
Summary: Laptop sometimes doesn't suspend when the lid is closed
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 22
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-08-03 22:16 UTC by Dima Ryazanov
Modified: 2015-09-11 06:41 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-09-11 06:41:56 UTC
Type: Bug

Attachments (Terms of Use)
dmesg (208.35 KB, text/plain)
2015-08-03 22:17 UTC, Dima Ryazanov
no flags Details
Suggested patch that solves my problem (707 bytes, patch)
2015-08-07 09:35 UTC, Oded Arbel
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1174480 0 unspecified CLOSED Laptop won't suspend after lid closing 2021-02-22 00:41:40 UTC

Internal Links: 1174480

Description Dima Ryazanov 2015-08-03 22:16:09 UTC
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).

Comment 1 Dima Ryazanov 2015-08-03 22:17:08 UTC
Created attachment 1058898 [details]

Comment 2 Jan Synacek 2015-08-04 08:10:40 UTC
This is a duplicate of #1174480. I'm leaving it open as a clone for Fedora 22.

Comment 3 Antonio Dias 2015-08-05 14:47:44 UTC
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
                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

Comment 4 Jóhann B. Guðmundsson 2015-08-06 13:51:36 UTC
(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.

Comment 5 Oded Arbel 2015-08-07 08:43:42 UTC
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)

Comment 6 Oded Arbel 2015-08-07 09:35:23 UTC
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.

Comment 7 Dima Ryazanov 2015-08-13 02:20:55 UTC
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.

Comment 9 Oded Arbel 2015-09-02 11:27:33 UTC
The above patch works for me - with that systemd I no longer have problems with automatic suspend.

Comment 10 drago01 2015-09-05 06:25:29 UTC
Does not work here see: https://bugzilla.redhat.com/show_bug.cgi?id=1244435#c15

Comment 11 Oded Arbel 2015-09-06 07:57:59 UTC
bug #1244435 doesn't seem related to the monitor count issue in systemd.

Comment 12 Elliott Sales de Andrade 2015-09-11 01:49:12 UTC
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?

Comment 13 Jan Synacek 2015-09-11 06:41:56 UTC
I have no idea. The new bodhi simply didn't link the bugs.

Fixed by https://bodhi.fedoraproject.org/updates/systemd-219-23.fc22

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