Bug 1526692

Summary: /sys/power/mem_sleep defaults to s2idle on ThinkPad X1 Tablet since 4.14 kernel, and breathing LED light not shown with s2idle sleep
Product: [Fedora] Fedora Reporter: Robin Lee <robinlee.sysu>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: airlied, ajax, bskeggs, dimitris.on.linux, ewk, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, mchehab, mjg59, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-08 11:04:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
backtrace from oops when trying to suspend. none

Description Robin Lee 2017-12-16 10:33:16 UTC 
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.
Comment 1 Robin Lee 2017-12-16 12:15:56 UTC 
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.
Comment 2 Dimitris 2017-12-16 23:12:23 UTC 
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.
Comment 3 Dimitris 2017-12-18 08:34:41 UTC 
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.
Comment 4 Dimitris 2017-12-18 08:38:08 UTC 
Created attachment 1369310 [details]
backtrace from oops when trying to suspend.
Comment 5 Robin Lee 2018-02-12 15:59:17 UTC 
Suspending works on kernel-core-4.15.2-300.fc27.x86_64.

But the breathing LED light is just off when system suspended.
Comment 6 Robin Lee 2018-03-04 09:28:56 UTC 
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
Comment 7 Hans de Goede 2018-03-04 10:59:26 UTC 
(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
Comment 8 Hans de Goede 2018-03-08 11:04:27 UTC 
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.