Description of problem: Failed to suspend on ThinkPad X1 Tablet. dmesg shows: Dec 16 18:15:29 cheese-X1tablet kernel: PM: suspend entry (s2idle) Dec 16 18:15:48 cheese-X1tablet kernel: PM: Syncing filesystems ... done. Dec 16 18:15:48 cheese-X1tablet kernel: Freezing user space processes ... (elapsed 0.002 seconds) done. Dec 16 18:15:48 cheese-X1tablet kernel: OOM killer disabled. Dec 16 18:15:48 cheese-X1tablet kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Dec 16 18:15:48 cheese-X1tablet kernel: Suspending console(s) (use no_console_suspend to debug) Dec 16 18:15:48 cheese-X1tablet kernel: sd 1:0:0:0: [sda] Synchronizing SCSI cache Dec 16 18:15:48 cheese-X1tablet kernel: sd 1:0:0:0: [sda] Stopping disk Dec 16 18:15:48 cheese-X1tablet kernel: PM: suspend devices took 0.383 seconds Dec 16 18:15:48 cheese-X1tablet kernel: ACPI: button: The lid device is not compliant to SW_LID. Dec 16 18:15:48 cheese-X1tablet kernel: sd 1:0:0:0: [sda] Starting disk Dec 16 18:15:48 cheese-X1tablet kernel: PM: resume devices took 0.200 seconds Dec 16 18:15:48 cheese-X1tablet kernel: OOM killer enabled. Dec 16 18:15:48 cheese-X1tablet kernel: Restarting tasks ... done. After showing 'ACPI: button: The lid device is not compliant to SW_LID.', the suspend procedure was stopped and the system resumed. Version-Release number of selected component (if applicable): kernel-core-4.14.6-300.fc27.x86_64 How reproducible: Always Steps to Reproduce: 1. systemctl suspend 2. 3. Actual results: System suspended. Expected results: Just GDM was locked and screen was blank, the system did not suspend. Additional info: The issue does not exist on 4.13 kernels, for example kernel-core-4.13.16-302.fc27.x86_64. The machine model is ThinkPad X1 Tablet. System product name is 20GGA00L00.
The issue seems not related to the message 'ACPI: button: The lid device is not compliant to SW_LID.'. The system is just resumed right after suspend.
I've had this happen 2-3 times with the 4.14 series in F27, on a Thinkpad X250. Very sporadic, so I don't have any relevant logs, at least not yet. Haven't seen a suspend failure on this laptop since a long while, maybe since I installed F24 on it back in 2015, so definitely looks like a regression.
Just reproduced here, tried to suspend the X250 using the GNOME status menu button and the Alt key - not the lid. Laptop is docked with an external display in use in addition to the laptop panel. Kernel version is 4.14.6-300.fc27.x86_64 Screen was blank, fan was running, but laptop was unresponsive. When I hit the Fn button, the laptop actually went into suspend. I then hit Fn again, and laptop resumed, at which point I saw the abrt message with the kernel oops. I'll attach that here.
Created attachment 1369310 [details] backtrace from oops when trying to suspend.
Suspending works on kernel-core-4.15.2-300.fc27.x86_64. But the breathing LED light is just off when system suspended.
With kernel >= 4.14, explicitly setting mem_sleep_default to 'deep' turns the breathing LED light back. The related commit is e870c6c87cf9484090d28f2a68aa29e008960c93: ACPI / PM: Prefer suspend-to-idle over S3 on some systems
(In reply to Robin Lee from comment #6) > With kernel >= 4.14, explicitly setting mem_sleep_default to 'deep' turns > the breathing LED light back. > > The related commit is e870c6c87cf9484090d28f2a68aa29e008960c93: > ACPI / PM: Prefer suspend-to-idle over S3 on some systems Hi, It is probably best to discuss this upstream, I think it would be good to send a mail to discuss this to the following addresses: Rafael J. Wysocki <rafael.j.wysocki> linux-acpi.org Please put me in the Cc: Hans de Goede <hdegoede> Thanks, Hans
Thank you for taking this up with upstream. This is now being tracked here: https://bugzilla.kernel.org/show_bug.cgi?id=199057 As upstream is a much better place to deal with this, I'm closing this bug now.