Due to a recent update on Javascript code a full page refresh on your browser might be needed.
Bug 1526692 - /sys/power/mem_sleep defaults to s2idle on ThinkPad X1 Tablet since 4.14 kernel, and breathing LED light not shown with s2idle sleep
Summary: /sys/power/mem_sleep defaults to s2idle on ThinkPad X1 Tablet since 4.14 kern...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-16 10:33 UTC by Robin Lee
Modified: 2018-03-08 11:04 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-08 11:04:27 UTC
Type: Bug


Attachments (Terms of Use)
backtrace from oops when trying to suspend. (5.72 KB, text/plain)
2017-12-18 08:38 UTC, Dimitris
no flags Details


Links
System ID Priority Status Summary Last Updated
Linux Kernel 199057 None None None 2019-04-09 18:16:05 UTC

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@intel.com>
linux-acpi@vger.kernel.org

Please put me in the Cc:
Hans de Goede <hdegoede@redhat.com>

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.


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