Bug 100171 - Unable to Wake the System Up from Suspend on Thinkpad Helix 2
Summary: Unable to Wake the System Up from Suspend on Thinkpad Helix 2
Status: CLOSED DOCUMENTED
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-20 17:33 UTC by Tom Li
Modified: 2017-09-16 10:18 UTC (History)
19 users (show)

See Also:
Kernel Version: 4.2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump for Thinkpad Helix 2 (594.93 KB, application/octet-stream)
2015-09-07 14:15 UTC, Tom Li
Details
dmesg from Linux 4.2 (54.53 KB, text/plain)
2015-09-07 14:16 UTC, Tom Li
Details
syslog during suspend without i915, thinkpad_acpi modules (302.35 KB, text/plain)
2016-01-31 19:08 UTC, jono
Details
dmesg without i915 (58.91 KB, text/plain)
2016-01-31 19:09 UTC, jono
Details
Test Results of suspend to mem with pm_test set to core (5.25 KB, text/plain)
2016-07-07 08:16 UTC, thomas.michel
Details
rtc_trace - dmesg after reboot after failed suspend to mem (66.30 KB, text/plain)
2016-07-07 08:38 UTC, thomas.michel
Details
New dmesg after failed suspend (66.54 KB, text/plain)
2016-07-07 09:49 UTC, thomas.michel
Details
Dmesg after pm_test set to core (4.79 KB, text/plain)
2016-07-25 15:22 UTC, Tudor Protopopescu
Details
Dmesg after echo core > /sys/power/pm_test (152.73 KB, text/plain)
2016-10-13 09:01 UTC, Tudor Protopopescu
Details
Dmesg after echo mem > /sys/power/state (199.50 KB, text/plain)
2016-10-13 09:03 UTC, Tudor Protopopescu
Details
Dmesg after successful wake up from suspend (243.19 KB, text/plain)
2017-02-18 08:10 UTC, Tudor Protopopescu
Details
Dmesg after wake up from freeze (196.12 KB, text/plain)
2017-02-18 08:28 UTC, Tudor Protopopescu
Details
ACPI Dump BIOS 1.91 (594.58 KB, text/plain)
2017-06-16 16:20 UTC, Tudor Protopopescu
Details
ACPI Dump BIOS 1.93 (594.58 KB, text/plain)
2017-06-16 16:20 UTC, Tudor Protopopescu
Details

Description Tom Li 2015-06-20 17:33:02 UTC
Dean Stanton wrote (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1424088):

> Lenovo ThinkPad Helix is a "Convertable Ultrabook" with an Intel Core-M
> ("Broadwell")
> processor. The tablet can come off the dock-with-keyboard and latch to it as
> a cover.

> Attempting a suspend is apparently successful. The LED (on the back of the
> tablet >pulsates).

> But neither attaching the tablet in its open position nor pressing the power
> button will wake the system to resume. The LED continues to pulsate and the
> system continues to be unreachable by Ethernet.

> As a "workaround" I can suspend with pm-suspend-hybrid and then when it does
> not resume I can force power off and turn it back on. This causes it to thaw.

> None of the pm-action "quirk" options helped.

I can confirm the issue with Linux 4.0.5. It seems the ACPI event is not accepted by the system?
Comment 1 Zhang Rui 2015-06-30 07:41:38 UTC
PLease follow https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
and attach the test result of pm_test and rtc trace.
Comment 2 Tom Li 2015-08-11 20:34:13 UTC
Since it still presents on Linux 4.1, I'm going to start debugging and I'll post my results soon.
Comment 3 Aaron Lu 2015-08-21 07:13:24 UTC
Please attach its acpidump and dmesg.
Comment 4 Aaron Lu 2015-09-01 03:20:59 UTC
ping
Comment 5 Tom Li 2015-09-07 14:14:54 UTC
Sorry for the delay. I can also confirmed with Linux 4.2.
Comment 6 Tom Li 2015-09-07 14:15:51 UTC
Created attachment 186991 [details]
acpidump for Thinkpad Helix 2

While dumping the ACPI, there is a warning:

$ acpidump > acpidump
Wrong checksum for FADT!

It seems the BIOS quality is not so good.
Comment 7 Tom Li 2015-09-07 14:16:30 UTC
Created attachment 187001 [details]
dmesg from Linux 4.2
Comment 8 Tom Li 2015-09-07 14:19:08 UTC
I followed Linus' guide from

/usr/src/linux/Documentation/power/s2ram.txt

to perform a quick test. The result is

[    0.523965]   Magic number: 0:788:178
[    0.523975]   hash matches drivers/base/power/main.c:1065
[    0.524045] acpi device:0e: hash matches
[    0.524069]  platform: hash matches
Comment 9 Tom Li 2015-09-07 14:50:52 UTC
I performed the pm_test:

freezer: 
    test works flawlessly.

devices:
    system may hang under X. tests in single-user mode showed an unclaimed register in i915, maybe the graphics card was unable to restore the original state and crashed.

        [   80.331379] ------------[ cut here ]------------
        [   80.331394] WARNING: CPU: 0 PID: 255 at drivers/gpu/drm/i915/intel_uncore.c:620 hsw_unclaimed_reg_debug+0x60/0x80 [i915]()
        [   80.331395] Unclaimed register detected after writing to register 0x71414
        [   80.331422] Modules linked in: hid_lenovo uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media usbhid btusb btintel bluetooth hid_sensor_hub mfd_core wacom snd_soc_sst_broadwell acer_wmi sparse_keymap hid_multitouch snd_soc_sst_haswell_pcm snd_soc_sst_ipc snd_soc_sst_dsp x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul arc4 crc32c_intel evdev psmouse serio_raw efivars iwlmvm mac80211 iwlwifi cfg80211 i915 intel_gtt i2c_algo_bit drm_kms_helper xhci_pci xhci_hcd drm processor_thermal_device intel_soc_dts_iosf iosf_mbi thermal wmi snd_soc_rt286 snd_soc_rl6347a thinkpad_acpi snd_soc_core snd_compress snd_pcm snd_timer nvram i2c_hid snd soundcore rfkill battery int3403_thermal ac snd_soc_sst_acpi video 8250_dw i2c_designware_platform i2c_designware_core
        [   80.331427]  i2c_core spi_pxa2xx_platform int3402_thermal int340x_thermal_zone int3400_thermal button acpi_thermal_rel processor sch_fq_codel efivarfs ipv6
        [   80.331429] CPU: 0 PID: 255 Comm: kworker/u16:6 Tainted: G        W       4.2.0-gentoo-r1 #2
        [   80.331430] Hardware name: LENOVO 20CGA00XCD/20CGA00XCD, BIOS N17ET78W (1.78 ) 06/26/2015
        [   80.331434] Workqueue: events_unbound async_run_entry_fn
        [   80.331437]  0000000000000000 ffffffffc06a6320 ffffffff8a497ad1 ffff8800c5667c18
        [   80.331438]  ffffffff8a0481c3 ffff8800c5c70000 0000000000071414 ffff8800c5c70080
        [   80.331440]  0000000000000246 0000000014050140 ffffffff8a048235 ffffffffc06a62e8
        [   80.331440] Call Trace:
        [   80.331444]  [<ffffffff8a497ad1>] ? dump_stack+0x47/0x67
        [   80.331447]  [<ffffffff8a0481c3>] ? warn_slowpath_common+0x73/0xa0
        [   80.331449]  [<ffffffff8a048235>] ? warn_slowpath_fmt+0x45/0x50
        [   80.331458]  [<ffffffffc0630720>] ? hsw_unclaimed_reg_debug+0x60/0x80 [i915]
        [   80.331464]  [<ffffffffc0631f3c>] ? gen8_write32+0xdc/0x150 [i915]
        [   80.331471]  [<ffffffffc05faca1>] ? intel_display_power_is_enabled+0x41/0x50 [i915]
        [   80.331476]  [<ffffffffc05ed41f>] ? i915_restore_state+0x12f/0x350 [i915]
        [   80.331480]  [<ffffffffc05eb02f>] ? i915_drm_resume+0x2f/0x140 [i915]
        [   80.331483]  [<ffffffff8a2932d0>] ? pci_pm_resume_noirq+0x90/0x90     
        [   80.331485]  [<ffffffff8a33da26>] ? dpm_run_callback.isra.11+0x26/0x70
        [   80.331486]  [<ffffffff8a33df1d>] ? device_resume+0x10d/0x200
        [   80.331488]  [<ffffffff8a33d900>] ? initcall_debug_start+0x60/0x60
        [   80.331489]  [<ffffffff8a33e024>] ? async_resume+0x14/0x40
        [   80.331491]  [<ffffffff8a063753>] ? async_run_entry_fn+0x33/0xd0
        [   80.331493]  [<ffffffff8a05c438>] ? process_one_work+0x128/0x390
        [   80.331495]  [<ffffffff8a05c6e5>] ? worker_thread+0x45/0x430
        [   80.331497]  [<ffffffff8a05c6a0>] ? process_one_work+0x390/0x390
        [   80.331499]  [<ffffffff8a0617dc>] ? kthread+0xbc/0xe0
        [   80.331501]  [<ffffffff8a061720>] ? kthread_worker_fn+0x150/0x150
        [   80.331503]  [<ffffffff8a49ca8f>] ? ret_from_fork+0x3f/0x70
        [   80.331505]  [<ffffffff8a061720>] ? kthread_worker_fn+0x150/0x150
        [   80.331505] ---[ end trace 4cdd14a7af602443 ]---

platform:
    tested in single-user mode, system is alive, no issue or oops.

processors:
    tested in single-user mode, system is alive, no issue or oops.

core:
    tested in single-user mode, system is alive, no issue or oops.

But, when I tried to make a real suspend,

none:
    tested in single-user mode, system is not able to wakeup after suspend, the LED-light is flashing, indicates the BIOS has been set to suspend mode, but the computer will be unable to wakeup. Pressing the power button doesn't work and the LED-light is still flashing. 

I'm highly doubt the issue is related to the firmware. The i915 is seems an isolated bug which is not the reason to prevent to computer to wake up.
Comment 10 Aaron Lu 2015-09-11 03:23:37 UTC
I wonder how did you do these tests? Since the power button can't resume the computer in the first place, or is it done for the hibernation case?
Comment 11 Tom Li 2015-09-11 14:12:41 UTC
> Aaron Lu: I wonder how did you do these tests? Since the power button can't
> resume the computer.

Did you read the kernel documentation?
https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

I think during freezer, devices, platform, processors and core tests, kernel is trying to partly put the system into suspend mode, and resume the system after few seconds, but as the document says

> except for the actual invocation of the platform firmware in order
> to put the system into the sleep state.

So the tests were done definitely without issue.
Comment 12 Aaron Lu 2015-09-14 02:31:01 UTC
(In reply to Tom Li from comment #11)
> > Aaron Lu: I wonder how did you do these tests? Since the power button can't
> resume the computer.
> 
> Did you read the kernel documentation?
> https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

I meant comment #8, I thought that was done with an actual suspend/hibernate.
Since all the pm_test works well, I don't see any reason to track which device failed the suspend/resume.

> 
> I think during freezer, devices, platform, processors and core tests, kernel
> is trying to partly put the system into suspend mode, and resume the system
> after few seconds, but as the document says
> 
> > except for the actual invocation of the platform firmware in order
> > to put the system into the sleep state.
> 
> So the tests were done definitely without issue.
Comment 13 Tom Li 2015-09-14 15:46:13 UTC
> I thought that was done with an actual suspend/hibernate.

No. It was done by suspending the system and cutting the power. Since the debugging magic number was stored in the Real Time Clock in the motherboard, you know...

> Since all the pm_test works well, I don't see any reason to track which
> device failed the suspend/resume.

This test is just yet another to confirm and prove the kernel itself works fine. We could see the last magic number matched acpi device:0e/platform. So it must be ACPI issues.
Comment 14 Aaron Lu 2015-09-15 02:14:27 UTC
(In reply to Tom Li from comment #8)
> I followed Linus' guide from
> 
> /usr/src/linux/Documentation/power/s2ram.txt
> 
> to perform a quick test. The result is
> 
> [    0.523965]   Magic number: 0:788:178
> [    0.523975]   hash matches drivers/base/power/main.c:1065

This corresponds to __device_suspend_noirq, which means the hash matches a value recorded in suspend_noirq phase.

> [    0.524045] acpi device:0e: hash matches
> [    0.524069]  platform: hash matches

But ->
(In reply to Tom Li from comment #9)
> I performed the pm_test:
> 
> 
> platform:
>     tested in single-user mode, system is alive, no issue or oops.

<-

The platform test here works well, and platform test includes all devices' noirq suspend callback, so it means __device_suspend_noirq doesn't cause problem.

> 
> processors:
>     tested in single-user mode, system is alive, no issue or oops.
> 
> core:
>     tested in single-user mode, system is alive, no issue or oops.

And the two above test mode not only did suspend_noirq, but also something more like disable non boot CPUs and suspend system core devices, which all went well.

It doesn't look like some device failed the suspend, but some other issues that caused the system failed to start wakeup and resume.
Comment 15 Aaron Lu 2015-09-15 02:15:44 UTC
(In reply to Tom Li from comment #9)
> I performed the pm_test:
> 
> freezer: 
>     test works flawlessly.
> 
> devices:
>     system may hang under X. tests in single-user mode showed an unclaimed
> register in i915, maybe the graphics card was unable to restore the original
> state and crashed.
> 
>         [   80.331379] ------------[ cut here ]------------
>         [   80.331394] WARNING: CPU: 0 PID: 255 at
> drivers/gpu/drm/i915/intel_uncore.c:620 hsw_unclaimed_reg_debug+0x60/0x80
> [i915]()
>         [   80.331395] Unclaimed register detected after writing to register
> 0x71414
>         [   80.331422] Modules linked in: hid_lenovo uvcvideo
> videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media
> usbhid btusb btintel bluetooth hid_sensor_hub mfd_core wacom
> snd_soc_sst_broadwell acer_wmi sparse_keymap hid_multitouch
> snd_soc_sst_haswell_pcm snd_soc_sst_ipc snd_soc_sst_dsp x86_pkg_temp_thermal
> intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul arc4 crc32c_intel
> evdev psmouse serio_raw efivars iwlmvm mac80211 iwlwifi cfg80211 i915
> intel_gtt i2c_algo_bit drm_kms_helper xhci_pci xhci_hcd drm
> processor_thermal_device intel_soc_dts_iosf iosf_mbi thermal wmi
> snd_soc_rt286 snd_soc_rl6347a thinkpad_acpi snd_soc_core snd_compress
> snd_pcm snd_timer nvram i2c_hid snd soundcore rfkill battery int3403_thermal
> ac snd_soc_sst_acpi video 8250_dw i2c_designware_platform i2c_designware_core
>         [   80.331427]  i2c_core spi_pxa2xx_platform int3402_thermal
> int340x_thermal_zone int3400_thermal button acpi_thermal_rel processor
> sch_fq_codel efivarfs ipv6
>         [   80.331429] CPU: 0 PID: 255 Comm: kworker/u16:6 Tainted: G       
> W       4.2.0-gentoo-r1 #2
>         [   80.331430] Hardware name: LENOVO 20CGA00XCD/20CGA00XCD, BIOS
> N17ET78W (1.78 ) 06/26/2015
>         [   80.331434] Workqueue: events_unbound async_run_entry_fn
>         [   80.331437]  0000000000000000 ffffffffc06a6320 ffffffff8a497ad1
> ffff8800c5667c18
>         [   80.331438]  ffffffff8a0481c3 ffff8800c5c70000 0000000000071414
> ffff8800c5c70080
>         [   80.331440]  0000000000000246 0000000014050140 ffffffff8a048235
> ffffffffc06a62e8
>         [   80.331440] Call Trace:
>         [   80.331444]  [<ffffffff8a497ad1>] ? dump_stack+0x47/0x67
>         [   80.331447]  [<ffffffff8a0481c3>] ? warn_slowpath_common+0x73/0xa0
>         [   80.331449]  [<ffffffff8a048235>] ? warn_slowpath_fmt+0x45/0x50
>         [   80.331458]  [<ffffffffc0630720>] ?
> hsw_unclaimed_reg_debug+0x60/0x80 [i915]
>         [   80.331464]  [<ffffffffc0631f3c>] ? gen8_write32+0xdc/0x150 [i915]
>         [   80.331471]  [<ffffffffc05faca1>] ?
> intel_display_power_is_enabled+0x41/0x50 [i915]
>         [   80.331476]  [<ffffffffc05ed41f>] ?
> i915_restore_state+0x12f/0x350 [i915]
>         [   80.331480]  [<ffffffffc05eb02f>] ? i915_drm_resume+0x2f/0x140
> [i915]
>         [   80.331483]  [<ffffffff8a2932d0>] ? pci_pm_resume_noirq+0x90/0x90
> 
>         [   80.331485]  [<ffffffff8a33da26>] ?
> dpm_run_callback.isra.11+0x26/0x70
>         [   80.331486]  [<ffffffff8a33df1d>] ? device_resume+0x10d/0x200
>         [   80.331488]  [<ffffffff8a33d900>] ? initcall_debug_start+0x60/0x60
>         [   80.331489]  [<ffffffff8a33e024>] ? async_resume+0x14/0x40
>         [   80.331491]  [<ffffffff8a063753>] ? async_run_entry_fn+0x33/0xd0
>         [   80.331493]  [<ffffffff8a05c438>] ? process_one_work+0x128/0x390
>         [   80.331495]  [<ffffffff8a05c6e5>] ? worker_thread+0x45/0x430
>         [   80.331497]  [<ffffffff8a05c6a0>] ? process_one_work+0x390/0x390
>         [   80.331499]  [<ffffffff8a0617dc>] ? kthread+0xbc/0xe0
>         [   80.331501]  [<ffffffff8a061720>] ? kthread_worker_fn+0x150/0x150
>         [   80.331503]  [<ffffffff8a49ca8f>] ? ret_from_fork+0x3f/0x70
>         [   80.331505]  [<ffffffff8a061720>] ? kthread_worker_fn+0x150/0x150
>         [   80.331505] ---[ end trace 4cdd14a7af602443 ]---
> 
> platform:
>     tested in single-user mode, system is alive, no issue or oops.
> 
> processors:
>     tested in single-user mode, system is alive, no issue or oops.
> 
> core:
>     tested in single-user mode, system is alive, no issue or oops.

BTW, do you see the above warning messages when you do the platform/processors/core test?
Comment 16 Aaron Lu 2015-11-26 02:56:42 UTC
Maybe worth to try to use rtcwake to wakeup the system to see if the system is capable of doing the resume, then we can decide why power button can't wake up the system.
Comment 17 Mike Sheldon 2015-12-23 11:56:43 UTC
I've just tested with rtcwake and the system doesn't resume. Resume from hibernation does work however.
Comment 18 Zhang Rui 2015-12-28 07:15:17 UTC
Please check if the problem still exists if the system boots w/o i915 graphics driver. Note that although the vga console may be unavailable in this case, you may still access the system and suspend/resume using things like netconsole.
Comment 19 jono 2016-01-09 08:08:50 UTC
I have the same issues and am happy to help debug. I wasn't able to boot without i915 (adding it to blacklist.conf didn't work, nor does forcing rmmod while in runlevel 3). However, following the instructions "a. Check if the resume hang is caused by graphics driver:" at https://01.org/linuxgraphics/documentation/development/how-debug-suspend-resume-issues seems to indicate that the graphics driver is not the issue (dmesg_after does not exist).
Comment 20 Tom Li 2016-01-09 08:30:26 UTC
I think these i915 oops is an independent minor problem on Broadwell graphics, since it presents during normal conditions, regardless to suspend or not. But graphics card itself can't not be excluded from the causes of the issue, in a SoC, everything is tied together, who knows.

We really need some helps from Lenovo engineers and developers, but little attention is paid on this model...
Comment 21 Aaron Lu 2016-01-11 02:02:20 UTC
(In reply to Tom Li from comment #20)
> I think these i915 oops is an independent minor problem on Broadwell
> graphics, since it presents during normal conditions, regardless to suspend
> or not. But graphics card itself can't not be excluded from the causes of
> the issue, in a SoC, everything is tied together, who knows.
> 
> We really need some helps from Lenovo engineers and developers, but little
> attention is paid on this model...

I agree. Is there a channel that we can reach the Lenovo engineers/support? I'm pretty sure they do not look here...
Comment 22 jono 2016-01-11 10:53:08 UTC
I sent an email to ibm-acpi-devel but got no response. Maybe if a few others respond and offer to help, it would get a response? It's pretty disappointing, because one of the reasons I got a thinkpad was that Lenovo has traditionally been good with their Linux support. I would guess there is an individual or team who are meant to be on this?

http://sourceforge.net/p/ibm-acpi/mailman/ibm-acpi-devel/
Comment 23 Johan Bernhardsson 2016-01-12 14:50:49 UTC
Any more information that can be tested? I'm on kernel 4.4.

There seem to be more than the thinkpad helix 2nd gen that is affected by this.

https://bbs.archlinux.org/viewtopic.php?id=181752

That one describes a similar symptom on thinkpad x1 carbon.
Comment 24 Aaron Lu 2016-01-13 01:59:35 UTC
Does Lenovo have a support forum? Post the problem there may catch their eyes.
Comment 25 Tom Li 2016-01-13 09:20:40 UTC
(In reply to jono from comment #22)
> It's pretty disappointing, because one of the reasons I got a 
> thinkpad was that Lenovo has traditionally been good with their
> Linux support.

It seems that problem is on this machine, although Lenovo made some efforts
on advertising, but they didn't pay any attention on consumer or technical
 support.

On the beginner of last year, just after I purchased it, I can't even
find useful information on the official website. I tried to order another power
adapter for convenience directly from consumer service, but they sent me the
wrong adapter, and they didn't believe that at first because they thought
I am the one who can't distinguish between Mini-USB and Power port... And there
was a time after I broke the hardware, and brought it to the service center,
"What's the model?" was the first question they asked me.

> Does Lenovo have a support forum?

This model belongs neither laptop nor tablets, I have checked some of the support forums, but I can't find a sub-forum for this model. I think both sides
are not in charge of this product is a possible reason of such service.

My temporary solution to this problem, is to remove suspend support from the
kernel since February 2014.... I appreciate if any one could find a support
forum or any channel that can make contact to Lenovo...

I don't recommend any one to buy it, even if they would run Windows.
Comment 26 jono 2016-01-30 23:15:37 UTC
I finally got a reply from ibm-acpi, who are friendly but clearly not getting enough support from Lenovo. They say it looks like a bug with the i915 module. To test this, I think one should unload the module and then try to suspend/resume. I can't seem to unload it as it's always in use, even if I change runlevel. I suppose one has to rebuild the kernel without the module. Some general tips here. https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
Comment 27 Tom Li 2016-01-31 04:45:40 UTC
I had chatted with some Windows developers about this suspend issue yesterday, 
and I learned much from them. Here is the most likely explanation of all the 
suspend issues, included but not limited to Thinkpad Helix 2.

On newer Intel CPU, a new ACPI power mode, S0ix, or ACPI_S0_LOW_POWER_IDLE was
introduced. This mode, enables more flexible sleep mode that gives applications 
and systems more control, for example, suspend most of the programs but still 
playing music, checking if any notification is pushed from server, trimming SSD,
with low power usage. e.g. make it possible to create an iPad-like device
on x86_64.

Obviously, it required userland and system support, Microsoft Windows utilizing
S0ix to implement called Connected Standby, or InstantGo, the suspend mechanism
since Windows 8.

But our trouble is on MOST of devices that SUPPORT S0ix, often comes with a
BROKEN S3 implementation (firmware or hardware level). Because Windows
never uses S3 anymore, it won't be a problem, S0ix is used instead. But on all
GNU/Linux platforms, we are running into broken S3 issue, we just can not use it.

The only solution is to implement a new sleep mode that uses S0ix instead of S3.
Some work was done by Google for their ChromeOS, but none of the code was 
mainlined yet.

Oh, what you probably realized, this feature is called "Lucid Sleep" by kernel
developers. we are not able to sleep our machines, until related code was
good enough, and received a green light from Linus Torvalds.
Comment 28 jono 2016-01-31 19:08:44 UTC
Created attachment 202471 [details]
syslog during suspend without i915, thinkpad_acpi modules

I boot up into a kernel without the i915 module, rmmod thinkpad_acpi, then shut the lid (at 18:35).
Comment 29 jono 2016-01-31 19:09:26 UTC
Created attachment 202481 [details]
dmesg without i915
Comment 30 jono 2016-01-31 19:16:24 UTC
So, it doesn't seem to be an issue with the video i915 driver (which is what was suspected by someone in ibm-acpi-dev. I recompiled the kernel without this module installed, booted into runlevel 3, and still can't resume. It also doesn't appear to be an issue with thinkpad_acpi, because I also removed this module (after boot) and still can't resume. I attach my syslog after booting up in this kernel, then closing the lid.
https://bugzilla.kernel.org/attachment.cgi?id=202471

The ACPI errors or events which look suspicious to me are: 


Jan 31 18:32:10 helix kernel: [    0.298178] ACPI Error: Needed type [Reference], found [Integer] ffff880223ed6ee8 (20160108/exresop-103)

Jan 31 18:32:10 helix kernel: [    0.298195] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20160108/dswexec-460)

Jan 31 18:32:10 helix kernel: [    0.298209] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] (Node ffff8802251026b8), AE_AML_OPERAND_TYPE (20160108/psparse-542)

and

Jan 31 18:32:10 helix kernel: [    0.484734] pci 0000:00:14.0: System wakeup disabled by ACPI

There is a 
Jan 31 18:32:10 helix kernel: [    0.292877] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
but this appears to be benign.

Have also attached my full dmesg.
Comment 31 Aaron Lu 2016-02-01 02:35:21 UTC
(In reply to Tom Li from comment #27)
> But our trouble is on MOST of devices that SUPPORT S0ix, often comes with a
> BROKEN S3 implementation (firmware or hardware level). Because Windows
> never uses S3 anymore, it won't be a problem, S0ix is used instead. But on

Oh yes, Windows is the de facto ACPI standard, not the SPEC :-\

> all
> GNU/Linux platforms, we are running into broken S3 issue, we just can not
> use it.

The firmware people should at least not providing _S3 in their ACPI table, that's not a lot of effort...

> 
> The only solution is to implement a new sleep mode that uses S0ix instead of
> S3.

We actually have that, though not good enough.
It's called freeze mode and can be entered by:
# echo freeze > /sys/power/state

It puts all processes to sleep, suspend devices and put processors into deep sleep.

> Some work was done by Google for their ChromeOS, but none of the code was 
> mainlined yet.
> 
> Oh, what you probably realized, this feature is called "Lucid Sleep" by
> kernel
> developers. we are not able to sleep our machines, until related code was
> good enough, and received a green light from Linus Torvalds.
Comment 32 Johan Bernhardsson 2016-02-01 07:19:26 UTC
freeze is actually working quite OK unless you unplugg the keyboard .. Then it dies.

It unloads modules on the helix as it should and the powers down.

When in that mode it only wakes up from they keyboard tho and not by pressing the power button. And the red light at the back does not blink as it does in sleep mode.

And it doesn't wake up from the lid switch either.
(In reply to Aaron Lu from comment #31)
> (In reply to Tom Li from comment #27)
> > But our trouble is on MOST of devices that SUPPORT S0ix, often comes with a
> > BROKEN S3 implementation (firmware or hardware level). Because Windows
> > never uses S3 anymore, it won't be a problem, S0ix is used instead. But on
> 
> Oh yes, Windows is the de facto ACPI standard, not the SPEC :-\
> 
> > all
> > GNU/Linux platforms, we are running into broken S3 issue, we just can not
> > use it.
> 
> The firmware people should at least not providing _S3 in their ACPI table,
> that's not a lot of effort...
> 
> > 
> > The only solution is to implement a new sleep mode that uses S0ix instead
> of
> > S3.
> 
> We actually have that, though not good enough.
> It's called freeze mode and can be entered by:
> # echo freeze > /sys/power/state
> 
> It puts all processes to sleep, suspend devices and put processors into deep
> sleep.
> 
> > Some work was done by Google for their ChromeOS, but none of the code was 
> > mainlined yet.
> > 
> > Oh, what you probably realized, this feature is called "Lucid Sleep" by
> > kernel
> > developers. we are not able to sleep our machines, until related code was
> > good enough, and received a green light from Linus Torvalds.


freeze is actually working quite OK unless you unplugg the keyboard .. Then it dies.

It unloads modules on the helix as it should and the powers down.

When in that mode it only wakes up from they keyboard tho and not by pressing the power button. And the red light at the back does not blink as it does in sleep mode.

And it doesn't wake up from the lid switch either.
Comment 33 Johan Bernhardsson 2016-02-01 07:25:33 UTC
freeze is actually working quite OK unless you unplugg the keyboard .. Then 
it dies.

It unloads modules on the helix as it should and the powers down.

When in that mode it only wakes up from they keyboard tho and not by 
pressing the power button. And the red light at the back does not blink as 
it does in sleep mode.

And it doesn't wake up from the lid switch either.




On February 1, 2016 03:35:29 bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=100171
>
> --- Comment #31 from Aaron Lu <aaron.lu@intel.com> ---
> (In reply to Tom Li from comment #27)
>> But our trouble is on MOST of devices that SUPPORT S0ix, often comes with a
>> BROKEN S3 implementation (firmware or hardware level). Because Windows
>> never uses S3 anymore, it won't be a problem, S0ix is used instead. But on
>
> Oh yes, Windows is the de facto ACPI standard, not the SPEC :-\
>
>> all
>> GNU/Linux platforms, we are running into broken S3 issue, we just can not
>> use it.
>
> The firmware people should at least not providing _S3 in their ACPI table,
> that's not a lot of effort...
>
>>
>> The only solution is to implement a new sleep mode that uses S0ix instead of
>> S3.
>
> We actually have that, though not good enough.
> It's called freeze mode and can be entered by:
> # echo freeze > /sys/power/state
>
> It puts all processes to sleep, suspend devices and put processors into deep
> sleep.
>
>> Some work was done by Google for their ChromeOS, but none of the code was
>> mainlined yet.
>>
>> Oh, what you probably realized, this feature is called "Lucid Sleep" by
>> kernel
>> developers. we are not able to sleep our machines, until related code was
>> good enough, and received a green light from Linus Torvalds.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 34 jono 2016-02-01 16:12:32 UTC
Yep, I can conform that echo freeze > /sys/power/state works. Interesting. At least I can now shut the lid from time to time. I still don't know who to report this bug to. Presumably acpi developers.
Comment 35 thomas.michel 2016-02-22 15:09:53 UTC
I am affected by this bug too. freeze does work, but only with keyboard attached. In tablet mode, nothing happens.
Comment 36 thomas.michel 2016-02-25 13:36:52 UTC
I noticed yesterday that not only Linux seems to be affected by this bug. I have the system running dual boot with Windows 10. Windows 10 does suspend/resume just fine in the connected standby mode, but when the system goes into hibernation due to battery running out it does not wake up either.

Maybe one of the other affected users can confirm this?
Comment 37 Tom Li 2016-02-26 06:10:50 UTC
(In reply to thomas.michel from comment #36)
> I noticed yesterday that not only Linux seems to be affected by this bug. I
> have the system running dual boot with Windows 10. Windows 10 does
> suspend/resume just fine in the connected standby mode, but when the system
> goes into hibernation due to battery running out it does not wake up either.

Oh the issue is starting to become more interesting. But I doubt if it related to the broken S3 issue. Hibernation is S4, not S3. However I'll check if S4 is working on my computer.
Comment 38 Michael Marley 2016-03-18 15:28:23 UTC
I have the exact same problem except with an older laptop, a Thinkpad T530.  It will suspend fine the first and sometimes second time in a row that I try it, but after that, it hangs before getting completely into suspend mode.  If I use pm_trace, I get the same "memory memory48: hash matches" message.  I can also reproduce the issue with kernel versions up through 4.5.

I can provide additional information about my system if you want it, but I didn't want to pollute this bug report if what I am encountering isn't the same issue.
Comment 39 Kevin Moraga 2016-03-22 22:26:28 UTC
I'm also affected by this bug. These are my tests: 

System: T460

Kernel 4.2: 
   - "echo freeze > /sys/power/state" works fine
   - "echo mem > /sys/power/state" not working

Kernel 4.3: 
   - "echo freeze > /sys/power/state" works fine
   - "echo mem > /sys/power/state" works fine

Kernel 4.4.5: 
   - "echo freeze > /sys/power/state" works fine
   - "echo mem > /sys/power/state" works fine
Comment 40 Johan Bernhardsson 2016-03-22 23:06:05 UTC
That is not the same bug.

If you had it mem would have failed on 4.3, 4.4, 4.5 (I haven't tested 4.2).

And it would be that it falls asleep and after that doesn't wake up at all 
when you press the power button or open the lid.

/Johan


On March 22, 2016 23:26:37 bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=100171
>
> --- Comment #39 from Kevin Moraga <kmoragas@riseup.net> ---
> I'm also affected by this bug. These are my tests:
>
> System: T460
>
> Kernel 4.2:
>    - "echo freeze > /sys/power/state" works fine
>    - "echo mem > /sys/power/state" not working
>
> Kernel 4.3:
>    - "echo freeze > /sys/power/state" works fine
>    - "echo mem > /sys/power/state" works fine
>
> Kernel 4.4.5:
>    - "echo freeze > /sys/power/state" works fine
>    - "echo mem > /sys/power/state" works fine
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 41 thomas.michel 2016-05-04 12:10:46 UTC
Hi, 

not sure if it's of any help, but I experienced the same problem on Windows 10 (I have a dual boot installation).

On Windows 10, the problem disappeared after uninstalling Intel Management Engine Driver - the system goes into suspend and wakes up properly.

Strange thing is that now in suspend mode the red light on the Thinkpad logo dos not blink any more but is completely off.

Back on Linux I blacklisted the mei kernel module but that did not help (tested on Vanilla 4.6 kernel on Fedora 23).
Comment 42 Zhang Rui 2016-05-09 03:03:39 UTC
interesting, as there is quite a lot of people in this thread, I'd like to give a summary of the problem, please confirm
1. all the issues are reported against Thinkpad platforms, please provide the model name if possible. (I need to update the summary to avoid misunderstanding)
2. freeze works for all of you, but suspend-to-mem does not.
3. rtcwake does not wake up all your platforms, when doing suspend-to-mem
4. can you check if hibernation works or not? As S4 doesn't work for windows, according to comment #36.
Comment 43 Zhang Rui 2016-05-09 03:04:46 UTC
I'd like to confirm all the reporters in this thread are experiencing exactly the same issue first. Or else, your answers will be misleading, when reading this thread. :)
Comment 44 Johan Bernhardsson 2016-05-09 03:44:21 UTC
1. Thinkpad helix 2
2. Yes
3. Yes
4. I can use pm-hibernate


On May 9, 2016 05:03:50 bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=100171
>
> --- Comment #42 from Zhang Rui <rui.zhang@intel.com> ---
> interesting, as there is quite a lot of people in this thread, I'd like to
> give
> a summary of the problem, please confirm
> 1. all the issues are reported against Thinkpad platforms, please provide the
> model name if possible. (I need to update the summary to avoid
> misunderstanding)
> 2. freeze works for all of you, but suspend-to-mem does not.
> 3. rtcwake does not wake up all your platforms, when doing suspend-to-mem
> 4. can you check if hibernation works or not? As S4 doesn't work for windows,
> according to comment #36.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 45 thomas.michel 2016-05-10 13:05:59 UTC
Hi,

1. Thinkpad Helix 2
2. echo freeze > /sys/power/state does not work if no keyboard is attached - system does not wake up any more. If a keyboard is attached, it does not even enter freeze mode (tested with vanill1 4.6 kernel)
3. Not sure how to test?
4. Hibernation does work both with or without keyboard attached
Comment 46 Zhang Rui 2016-05-11 01:34:58 UTC
(In reply to thomas.michel from comment #45)
> Hi,
> 
> 1. Thinkpad Helix 2
> 2. echo freeze > /sys/power/state does not work if no keyboard is attached -
> system does not wake up any more. If a keyboard is attached, it does not
> even enter freeze mode (tested with vanill1 4.6 kernel)

Interesting, it seems that the symptom is different, even on the same model?
Johan, please attach your kernel config.
Thomas, please rebuild your kernel with Johan' kernel config and see if freeze works or not.

> 3. Not sure how to test?
hmm, I think you can install rtcwake tool, and run
"rtcwake -s 30 -m mem" and see if the system resumes after 30 seconds.


(In reply to thomas.michel from comment #36)
> I noticed yesterday that not only Linux seems to be affected by this bug. I
> have the system running dual boot with Windows 10. Windows 10 does
> suspend/resume just fine in the connected standby mode, but when the system
> goes into hibernation due to battery running out it does not wake up either.
> 
Thomas,
is there anyway you can put windows 10 to hibernation, say, via the start menu, and check if hibernation works or not?
Comment 47 thomas.michel 2016-05-12 10:19:52 UTC
(In reply to Zhang Rui from comment #46)
> Interesting, it seems that the symptom is different, even on the same model?

It seems to be dependent of the configuration - the Helix has an attachable keyboard (which is more than just a keyboard, it also has an addition battery, USB port, DVI port and sound card). If this keyboard is attahced freeze does nothing for me, if it is not attached, system freezes and won't wake up any more,.


> > 3. Not sure how to test?
> hmm, I think you can install rtcwake tool, and run
> "rtcwake -s 30 -m mem" and see if the system resumes after 30 seconds.

Tried this, system does not wake up.
 

> Thomas,
> is there anyway you can put windows 10 to hibernation, say, via the start
> menu, and check if hibernation works or not?

In Windows 10, there is no option to actually hibernate any more. It seems windows has different levels of energy saving, as my windows is in German I cannot give you the correct english terms, I guess it's sleep and suspend.
The system wakes up from sleep just fine, not from suspend. The visual difference is that in sleep mode the red LED on the thinkpad logo is completely off while in suspend it is slowly flashing. 
Basically it's the same in Windows as in Linux: Once the LED is slowly flashing, you cannot wake up the system any more.
Comment 48 Zhang Rui 2016-05-13 01:05:52 UTC
(In reply to thomas.michel from comment #47)
> (In reply to Zhang Rui from comment #46)
> > Interesting, it seems that the symptom is different, even on the same
> model?
> 
> It seems to be dependent of the configuration - the Helix has an attachable
> keyboard (which is more than just a keyboard, it also has an addition
> battery, USB port, DVI port and sound card). If this keyboard is attahced
> freeze does nothing for me,

please attach the dmesg output after "echo freeze > /sys/power/state"

> if it is not attached, system freezes and won't
> wake up any more,.

please add "no_console_suspend" boot option and check if you can see anything in the screen upon resume.
BTW, when you say freezes, you mean the system does react upon resume (the LED light is on, the fan starts to spin, etc), but you can never bring back your screen, right?

please read this paper
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
and follow the instructions in section 4.3.
Comment 49 thomas.michel 2016-05-16 16:42:56 UTC
This is the dmesg after trying to freeze with keyboard attached:

[ 1977.768834] SELinux: the above unknown classes and permissions will be allowed
[ 3962.947313] PM: Syncing filesystems ... done.
[ 3962.977172] PM: Preparing system for sleep (freeze)
[ 3962.985533] Freezing user space processes ... (elapsed 0.002 seconds) done.
[ 3962.987602] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 3962.988725] PM: Suspending system (freeze)
[ 3962.988727] Suspending console(s) (use no_console_suspend to debug)
[ 3962.988953] wlp6s0: deauthenticating from 00:25:84:86:4d:00 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 3963.119664] sd 3:0:0:0: [sda] Synchronizing SCSI cache
[ 3963.121134] sd 3:0:0:0: [sda] Stopping disk
[ 3963.931845] PM: suspend of devices complete after 942.936 msecs
[ 3963.947621] PM: late suspend of devices complete after 15.772 msecs
[ 3963.951317] xhci_hcd 0000:00:14.0: System wakeup enabled by ACPI
[ 3963.962227] PM: noirq suspend of devices complete after 14.092 msecs
[ 3963.975626] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 3963.975764] PM: noirq resume of devices complete after 13.535 msecs
[ 3964.172666] PM: early resume of devices complete after 187.068 msecs
[ 3964.174065] rtc_cmos 00:02: System wakeup disabled by ACPI
[ 3964.174434] iwlwifi 0000:06:00.0: L1 Enabled - LTR Enabled
[ 3964.174891] iwlwifi 0000:06:00.0: L1 Enabled - LTR Enabled
[ 3964.175802] sd 3:0:0:0: [sda] Starting disk
[ 3964.237950] iwlwifi 0000:06:00.0: L1 Enabled - LTR Enabled
[ 3964.238721] iwlwifi 0000:06:00.0: L1 Enabled - LTR Enabled
[ 3964.444714] usb 1-3.3: reset high-speed USB device number 5 using xhci_hcd
[ 3964.476738] ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3964.478449] ata4.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[ 3964.478453] ata4.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 3964.478494] ata4.00: ACPI cmd ef/10:09:00:00:00:a0 (SET FEATURES) succeeded
[ 3964.478709] ata4.00: supports DRM functions and may not be fully accessible
[ 3964.479498] ata4.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[ 3964.479500] ata4.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
[ 3964.479536] ata4.00: ACPI cmd ef/10:09:00:00:00:a0 (SET FEATURES) succeeded
[ 3964.479730] ata4.00: supports DRM functions and may not be fully accessible
[ 3964.480141] ata4.00: configured for UDMA/133
[ 3964.855798] psmouse serio1: synaptics: queried max coordinates: x [..5712], y [..4780]
[ 3964.886606] psmouse serio1: synaptics: queried min coordinates: x [1232..], y [1074..]
[ 3965.045472] PM: resume of devices complete after 872.797 msecs
[ 3965.045942] PM: Finishing wakeup.
[ 3965.045944] Restarting tasks ... done.
[ 3966.611754] thinkpad_acpi: unhandled HKEY event 0x4012
[ 3966.611758] thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel@lists.sourceforge.net
[ 3968.350624] wlp6s0: authenticate with 00:25:84:b3:a4:a0
[ 3968.355021] wlp6s0: send auth to 00:25:84:b3:a4:a0 (try 1/3)
[ 3968.355902] wlp6s0: authenticated
[ 3968.356678] wlp6s0: associate with 00:25:84:b3:a4:a0 (try 1/3)
[ 3968.358979] wlp6s0: RX AssocResp from 00:25:84:b3:a4:a0 (capab=0x111 status=0 aid=3)
[ 3968.361328] wlp6s0: associated
[ 3968.438765] wlp6s0: Limiting TX power to 20 (23 - 3) dBm as advertised by 00:25:84:b3:a4:a0
Comment 50 thomas.michel 2016-05-16 16:50:13 UTC
Hi,

> 
> please add "no_console_suspend" boot option and check if you can see
> anything in the screen upon resume.

No, nothing to see. Did the command from a console (no GUI) session, the screen goes black and comes back again.

> BTW, when you say freezes, you mean the system does react upon resume (the
> LED light is on, the fan starts to spin, etc), but you can never bring back
> your screen, right?
> 

You can not see or hear anything on the Helix as it has no fan or anything, so I can't tell.
Comment 51 Zhang Rui 2016-05-17 01:57:54 UTC
(In reply to thomas.michel from comment #50)
> Hi,
> 
> > 
> > please add "no_console_suspend" boot option and check if you can see
> > anything in the screen upon resume.
> 
> No, nothing to see. Did the command from a console (no GUI) session, the
> screen goes black and comes back again.
> 
I mean you should check your screen when doing suspend to mem.

BTW, does the problem still exists if the Intel Management Engine feature is disabled in BIOS, if there is any?

For the others, please confirm the symptom described in comment #41?
Comment 52 thomas.michel 2016-05-18 11:24:19 UTC
OK, tested again:

echo mem > /sys/power/state
System goes to freeze mode -> Red Thinkpad LED slowly blinking, screeen off. System cannot wake up with keyboard, windows button (the Helix has a windows button as it is a Tablet/Laptop hybrid model) or power button. System is not dead as pushing the Windows button still vibrates on pushing it.
This happens both with keyboard dock attached or detached.

echoe freeze > /sys/power/state
system goes to suspend to memory -> Red Thinkpad LED off, screeen off. System is not dead as pushing the Windows button still vibrates on pushing it. Neither Power button or windows button wakes system up.
This happens with keyboard dock detached.

With keyboard dock attached I get mixed results - sometimes nothing happens, sometimes it works half as expected - Thinkpad LED off, screen off. System wakes up after pressing any key - but not with the power button on the tablet (the keyboard dock has no dedicated power button).

The results in Windows are similar but not the same - once the Thinkpad LED blinks slowly, the system will never wake up. If the Thinkpad LED is off (like in freeze), system wake up both using power button on tablet and keyboard.

All this is independent of the Intel Management engine settings in BIOS. I tried to enable it to see if the system can wake up from a remote console (Serial over Lan) but did not yet manage to get that feature working at all.

Let me know if I can do any further testing.
Comment 53 Zhang Rui 2016-05-19 03:05:53 UTC
(In reply to thomas.michel from comment #52)
> The results in Windows are similar but not the same - once the Thinkpad LED
> blinks slowly, the system will never wake up. If the Thinkpad LED is off
> (like in freeze), system wake up both using power button on tablet and
> keyboard.

when will LED blink slowly and when is LED turned off in windows?
Comment 54 Zhang Rui 2016-05-19 03:09:40 UTC
        Device (PWRB)
        {
            Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */)  // _HID: Hardware ID
            Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
            {
                Return (Package (0x02)
                {
                    0x00, 
                    0x00
                })
            }
            ...
         }

AFAICS, the control method power button implementation on this platform is broken. Thus it's possible that you can not wake up your system via power button, either in windows or in Linux.

can you please try to use "rtcwake -s 30 -m mem" to suspend and see if the system comes back after around 30 seconds?
Comment 55 thomas.michel 2016-05-19 08:33:53 UTC
(In reply to Zhang Rui from comment #53)

> 
> when will LED blink slowly and when is LED turned off in windows?

When chosing "sleep" from the Start Menu, the LED does not blink, so I think that's similar to "freeze".

I cannot actually reproduce the blinking mode as Windows just lets me select sleep or hibernate (with hibernation working)k But sometimes I see Windows go into that mode which lets the LED slowly bling and then I cannot wake up the system any more.
Comment 56 thomas.michel 2016-05-19 08:34:42 UTC
(In reply to Zhang Rui from comment #54)

> can you please try to use "rtcwake -s 30 -m mem" to suspend and see if the
> system comes back after around 30 seconds?

No, it does not come back.
Comment 57 Tom Li 2016-05-19 14:03:40 UTC
> System is not dead as pushing the Windows button still vibrates
on pushing it.

No, the system IS DEAD. The Windows button by design, as long as the
tablet is switched on, even without any driver, the vibrator will be activated.
Comment 58 Tom Li 2016-05-19 14:12:02 UTC
(In reply to Zhang Rui from comment #54)


>             Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */)  //
> _HID: Hardware ID
>             Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for
> Wake
>             {
>                 Return (Package (0x02)
>                 {
>                     0x00, 
>                     0x00
>                 })
>             }
> AFAICS, the control method power button implementation on this platform is
> broken. 

This confirms the "broken s3" explanation I got from some 
Windows developers, and the nice catch is even better, now we can understand
how broken it is: do nothing for the power button.

How defective by design it is! I doubt if a solution could exist.
Comment 59 Johan Bernhardsson 2016-05-19 15:03:10 UTC
cat /proc/acpi/wakeup lists power button as S0 and sleep button as S3
lid as S4.

So what state does it end up in on sleep in linux? If it is S3 and we 
 have no sleep button. That might explains why it won't wake up. And
also why the lid doesn't react. 

/Johan

On Thu, 2016-05-19 at 14:12 +0000, bugzilla-daemon@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=100171
> 
> --- Comment #58 from Tom Li <biergaizi2009@gmail.com> ---
> (In reply to Zhang Rui from comment #54)
> 
> 
> >             Name (_HID, EisaId ("PNP0C0C") /* Power Button Device
> > */)  //
> > _HID: Hardware ID
> >             Method (_PRW, 0, NotSerialized)  // _PRW: Power
> > Resources for
> > Wake
> >             {
> >                 Return (Package (0x02)
> >                 {
> >                     0x00, 
> >                     0x00
> >                 })
> >             }
> > AFAICS, the control method power button implementation on this
> > platform is
> > broken. 
> 
> This confirms the "broken s3" explanation I got from some 
> Windows developers, and the nice catch is even better, now we can
> understand
> how broken it is: do nothing for the power button.
> 
> How defective by design it is! I doubt if a solution could exist.
>
Comment 60 Johan Bernhardsson 2016-05-19 15:19:42 UTC
rtcwake -s 30 -m freeze works

rtcwake -s 30 -m mem  does not work

/Johan

On Thu, 2016-05-19 at 03:09 +0000, bugzilla-daemon@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=100171
> 
> --- Comment #54 from Zhang Rui <rui.zhang@intel.com> ---
>         Device (PWRB)
>         {
>             Name (_HID, EisaId ("PNP0C0C") /* Power Button Device */)
>   // _HID:
> Hardware ID
>             Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources
> for Wake
>             {
>                 Return (Package (0x02)
>                 {
>                     0x00, 
>                     0x00
>                 })
>             }
>             ...
>          }
> 
> AFAICS, the control method power button implementation on this
> platform is
> broken. Thus it's possible that you can not wake up your system via
> power
> button, either in windows or in Linux.
> 
> can you please try to use "rtcwake -s 30 -m mem" to suspend and see
> if the
> system comes back after around 30 seconds?
>
Comment 61 Zhang Rui 2016-05-20 00:07:20 UTC
(In reply to Johan Bernhardsson from comment #60)
> rtcwake -s 30 -m freeze works
>
good to know. so rtcwake actually works on this laptop.
 
> rtcwake -s 30 -m mem  does not work
> 
This means the system actually hangs during suspend. And the broken ACPI control method Power button is another issue, which takes no effect to this.

please follow section 4.3 of this BKM
https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
and attach the test results.
Comment 62 thomas.michel 2016-05-25 10:50:11 UTC
(In reply to Zhang Rui from comment #61)

> please follow section 4.3 of this BKM
> https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-
> issues
> and attach the test results.

I looked at the instructions but am not sure what to do - my system has no file named /var/log/kern.log
Comment 63 Zhang Rui 2016-05-26 02:04:39 UTC
then ignore this one and attach the others.
Comment 64 Zhang Rui 2016-06-20 02:06:39 UTC
ping...
Comment 65 thomas.michel 2016-06-20 18:43:33 UTC
Hi,

I am not sure what to attach. Here's what it says in chapter 4.3:


Check if this is a regression.
 - not sure what that means

If not, check if this is a graphics issue.
 - does not seem so

If not, check if this is a driver specific issue.
 - cannot tell

If the problem still exists, file a suspend/hibernate bug [Platform] {STI, STR, HTD}: system hangs during suspend/resume, together with the serial console output/screenshot after the problem was reproduced, the contents of /var/log/kern.log, and the test results of disk mode (HTD only), pm_test, pm_async, and rtc trace.

var/log/kern.log does not exist, I do not have a serial console, and pm_test, pm_async or rtc are not available commands on my system.

I'ld like to be of help, but these instructions are a bit unclear to me.
Comment 66 Zhang Rui 2016-06-27 05:34:52 UTC
(In reply to thomas.michel from comment #65)
> Hi,
> 
> I am not sure what to attach. Here's what it says in chapter 4.3:
> 
> 
> Check if this is a regression.
>  - not sure what that means
> 
> If not, check if this is a graphics issue.
>  - does not seem so
> 
> If not, check if this is a driver specific issue.
>  - cannot tell
> 
> If the problem still exists, file a suspend/hibernate bug [Platform] {STI,
> STR, HTD}: system hangs during suspend/resume, together with the serial
> console output/screenshot after the problem was reproduced, the contents of
> /var/log/kern.log, and the test results of disk mode (HTD only), pm_test,
> pm_async, and rtc trace.
> 
> var/log/kern.log does not exist, I do not have a serial console, and
> pm_test, pm_async or rtc are not available commands on my system.
> 
> I'ld like to be of help, but these instructions are a bit unclear to me.

the hyper links in the original document got lost when the document is published. So you need to read the previous chapters, which defines "regression", "graphics issue", "driver specific issue", "pm_test", "pm_async" and "rtc wake".
Comment 67 Ben Klopfenstein 2016-07-06 04:44:10 UTC
I just ordered a used Helix 2nd Gen, and it's going to arrive in about a week. Once it does, I'd be happy to help in any way possible here.

After reading through this bug report I decided to check for BIOS updates on Lenovo's site, and http://support.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-helix-series-laptops/thinkpad-helix-type-20cg-20ch/downloads/DS102026 has an update (v1.86) that was released 5/24/2016. The notes mention "(Fix) Fixed an issue where system might not resume from hibernate with Intel PTT on Windows 10." - Since this certainly addresses deficiencies in and makes changes to one suspend state, I'd say it's possible it may also affect others.

Note that these updates are made available as an EFI bootable ISO, and the helix has no optical drive, so I'd be surprised if all the testers here are on the latest BIOS revision.
Comment 68 thomas.michel 2016-07-07 08:16:00 UTC
Created attachment 222321 [details]
Test Results of suspend to mem with pm_test set to core
Comment 69 thomas.michel 2016-07-07 08:38:00 UTC
Created attachment 222341 [details]
rtc_trace - dmesg after reboot after failed suspend to mem
Comment 70 thomas.michel 2016-07-07 08:44:14 UTC
(In reply to Zhang Rui from comment #61)

> please follow section 4.3 of this BKM
> https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-
> issues
> and attach the test results

Hi,

attached two filed. When issuing the command echo mem > /sys/power/state after setting pm_test to core, the system wakes up fine after 5 seconds, dmesg is attached.

Setting pm_async to 0 does not have any effect.

Attached dmesg after reboot resulting in a failed suspend to mem, CONFIG_PM_TRACE_RTC is set to y in kernel config.

Regards,

Tom.
Comment 71 thomas.michel 2016-07-07 08:45:36 UTC
(In reply to Ben Klopfenstein from comment #67)

> After reading through this bug report I decided to check for BIOS updates on
> Lenovo's site, and
> http://support.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-helix-
> series-laptops/thinkpad-helix-type-20cg-20ch/downloads/DS102026 has an
> update (v1.86) that was released 5/24/2016. The notes mention "(Fix) Fixed
> an issue where system might not resume from hibernate with Intel PTT on
> Windows 10." - Since this certainly addresses deficiencies in and makes
> changes to one suspend state, I'd say it's possible it may also affect
> others.
> 
> Note that these updates are made available as an EFI bootable ISO, and the
> helix has no optical drive, so I'd be surprised if all the testers here are
> on the latest BIOS revision.

Hi,

I have updated to this BIOS version and it does not make any difference.

Regards,

Tom.
Comment 72 thomas.michel 2016-07-07 09:49:58 UTC
Created attachment 222361 [details]
New dmesg after failed suspend

Hi,

this is a dmesg output after a failed suspend. What I can see is this:

[    1.555605]   Magic number: 1:0:0
[    1.555666] memory memory48: hash matches
[    1.555739] rtc_cmos 00:02: setting system clock to 2001-01-01 00:00:21 UTC (978307221)

BTW: echoing mem to /sys/power/state works in all pm_test modes, meaning the system wakes up properly after 5 seconds. I does not wake up with pm_test set to none.
Comment 73 Tudor Protopopescu 2016-07-25 15:22:35 UTC
Created attachment 225921 [details]
Dmesg after pm_test set to core
Comment 74 Tudor Protopopescu 2016-07-25 15:25:47 UTC
(In reply to Zhang Rui from comment #42)

> 1. all the issues are reported against Thinkpad platforms, please provide the
> > model name if possible. (I need to update the summary to avoid 
> misunderstanding)
> 2. freeze works for all of you, but suspend-to-mem does not.
> 3. rtcwake does not wake up all your platforms, when doing suspend-to-mem
> 4. can you check if hibernation works or not? As S4 doesn't work for windows,
> > according to comment #36.


1. Thinkpad Helix 2 
	
2. echo freeze > /sys/power/state  works but only with `no_console_suspend' set. Without `no_console_suspend' the computer resumes immediately from freeze.
Same results with `rtcwake -s 30 freeze'.
	
Also freeze can only be resumed with keyboard input (only if the keyboard was attached when freeze initiated, freezing without keyboard attached and attaching after does not wake the computer), computer does not respond to power button or touch input. 

3. Yes

5. Hibernation works with `echo [shutdown/reboot] > /sys/power/disk' (or equivalent setting via systemd), does not work in `platform' mode. With platform mode hibernate hangs during resume. 

Suspend and hibernate work as expected in Windows 10 with Intel management still installed. 

Suspend works with pm_test set to 'core'.

pm_async does not make a difference. 

I'm more than happy to help debug, please let me know what I can do.
Comment 75 RussianNeuroMancer 2016-08-15 07:23:00 UTC
Anyone tested new intel-vbtn driver? (introduced since Linux 4.8)

Results of testing this driver on Dell Venue 11 Pro 7140: https://bugzilla.kernel.org/show_bug.cgi?id=102281#c66
Comment 76 Tudor Protopopescu 2016-08-16 02:17:59 UTC
Installed kernel 4.8.0-rc1, intel_vbtn loaded. Unfortunately it did not make a difference for me.
Comment 77 Chen Yu 2016-09-22 06:18:21 UTC
(In reply to Tudor Protopopescu from comment #74)
> (In reply to Zhang Rui from comment #42)
> 
> > 1. all the issues are reported against Thinkpad platforms, please provide
> the > model name if possible. (I need to update the summary to avoid 
> > misunderstanding)
> > 2. freeze works for all of you, but suspend-to-mem does not.
> > 3. rtcwake does not wake up all your platforms, when doing suspend-to-mem
> > 4. can you check if hibernation works or not? As S4 doesn't work for
> windows, > according to comment #36.
> 
> 
> 1. Thinkpad Helix 2 
>       
> 2. echo freeze > /sys/power/state  works but only with `no_console_suspend'
> set. Without `no_console_suspend' the computer resumes immediately from
> freeze.
> Same results with `rtcwake -s 30 freeze'.
>       
> Also freeze can only be resumed with keyboard input (only if the keyboard
> was attached when freeze initiated, freezing without keyboard attached and
> attaching after does not wake the computer), computer does not respond to
> power button or touch input. 
> 
> 3. Yes
> 
> 5. Hibernation works with `echo [shutdown/reboot] > /sys/power/disk' (or
> equivalent setting via systemd), does not work in `platform' mode. With
> platform mode hibernate hangs during resume. 
> 
> Suspend and hibernate work as expected in Windows 10 with Intel management
> still installed. 
> 
> Suspend works with pm_test set to 'core'.
> 
> pm_async does not make a difference. 
> 
> I'm more than happy to help debug, please let me know what I can do.

These are different problems, let's first focus on the original issue:
Unable to wake up from rtcwake -m mem -s 30, and system remain suspended.


1. what is the output of 
   /proc/acpi/wakeup before suspend?
2. what is the output of 
   ls -l /sys/class/rtc/rtc0/device/subsystem
3. what is the output of 
   grep . /sys/class/rtc/rtc0/device/power/*
4. what is the output of 
    sudo hwclock -r  and
    date
5. does the led light remain off, or does the fan spin, after
   suspend the system by 'rtcwake -m mem -s 30' ?


Anyway this looks like a bios issue to me.
Comment 78 Chen Yu 2016-09-22 06:26:28 UTC
BTW, please test with 
'no_console_suspend ignore_loglevel' appended in the cmdline.
and provide the dmesg of the result from:
echo core > /sys/power/pm_test
echo mem > /sys/power/state
Comment 79 Chen Yu 2016-10-06 12:34:52 UTC
ping
Comment 80 Tudor Protopopescu 2016-10-13 08:53:47 UTC
(In reply to Chen Yu from comment #77)
> 
> These are different problems, let's first focus on the original issue:
> Unable to wake up from rtcwake -m mem -s 30, and system remain suspended.
> 
> 
> 1. what is the output of 
>    /proc/acpi/wakeup before suspend?

Device  S-state   Status   Sysfs node
LID       S4    *enabled   platform:PNP0C0D:00
SLPB      S3    *enabled   platform:PNP0C0E:00
IGBE      S4    *disabled
PXSX      S4    *disabled
EXP2      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:06:00.0
PXSX      S4    *disabled
XHCI      S3    *enabled   pci:0000:00:14.0
EHC1      S3    *disabled
PWRB      S0    *enabled   platform:PNP0C0C:00

> 2. what is the output of 
>    ls -l /sys/class/rtc/rtc0/device/subsystem

lrwxrwxrwx 1 root root 0 Oct 13  2016 /sys/class/rtc/rtc0/device/subsystem -> ../../../bus/pnp

> 3. what is the output of 
>    grep . /sys/class/rtc/rtc0/device/power/*

/sys/class/rtc/rtc0/device/power/async:disabled
grep: /sys/class/rtc/rtc0/device/power/autosuspend_delay_ms: Input/output error
/sys/class/rtc/rtc0/device/power/control:auto
/sys/class/rtc/rtc0/device/power/runtime_active_kids:0
/sys/class/rtc/rtc0/device/power/runtime_active_time:0
/sys/class/rtc/rtc0/device/power/runtime_enabled:disabled
/sys/class/rtc/rtc0/device/power/runtime_status:unsupported
/sys/class/rtc/rtc0/device/power/runtime_suspended_time:0
/sys/class/rtc/rtc0/device/power/runtime_usage:0
/sys/class/rtc/rtc0/device/power/wakeup:enabled
/sys/class/rtc/rtc0/device/power/wakeup_abort_count:0
/sys/class/rtc/rtc0/device/power/wakeup_active:0
/sys/class/rtc/rtc0/device/power/wakeup_active_count:0
/sys/class/rtc/rtc0/device/power/wakeup_count:0
/sys/class/rtc/rtc0/device/power/wakeup_expire_count:0
/sys/class/rtc/rtc0/device/power/wakeup_last_time_ms:4156
/sys/class/rtc/rtc0/device/power/wakeup_max_time_ms:0
/sys/class/rtc/rtc0/device/power/wakeup_prevent_sleep_time_ms:0
/sys/class/rtc/rtc0/device/power/wakeup_total_time_ms:0

> 4. what is the output of 
>     sudo hwclock -r  and
>     date

2016-10-13 11:12:04.233288+3:00

Thu Oct 13 11:12:24 MSK 2016


> 5. does the led light remain off, or does the fan spin, after
>    suspend the system by 'rtcwake -m mem -s 30' ?

The led pulses every 4 seconds or so. The helix does not have a fan. It appears to be as 'off' as it should be in suspend.
Comment 81 Tudor Protopopescu 2016-10-13 09:01:57 UTC
Created attachment 241621 [details]
Dmesg after echo core > /sys/power/pm_test
Comment 82 Tudor Protopopescu 2016-10-13 09:03:12 UTC
Created attachment 241631 [details]
Dmesg after echo mem > /sys/power/state
Comment 83 Tudor Protopopescu 2016-10-13 09:07:32 UTC
(In reply to Chen Yu from comment #78)
> BTW, please test with 
> 'no_console_suspend ignore_loglevel' appended in the cmdline.
> and provide the dmesg of the result from:
> echo core > /sys/power/pm_test
> echo mem > /sys/power/state

Attached dmesg after executing each.

After 'echo mem > /sys/power/state', some messages scroll down the screen, the led flashes and the screen turns off, then the computer resumes immediately, it does not resume after 'rtcwake -m mem -s 30'.

Sorry for late reply, I have not had access to the computer for a while. Let me know what else I can help with.
Comment 84 RussianNeuroMancer 2016-11-10 20:34:47 UTC
Hi, Chen

Some additional info is needed?
Comment 85 Tudor Protopopescu 2016-11-24 10:02:00 UTC
(In reply to RussianNeuroMancer from comment #84)
> Hi, Chen
> 
> Some additional info is needed?

Yes, I'm happy to provide what information I can. Just let me know if more is needed.
Comment 86 Christian Krafft 2016-11-28 19:51:15 UTC
Hi there,

I just bought the same hardware a few weeks ago and ran into the same issue.
After upgrading UEFI-Bios to N17ET90W (1.90), using n17ur44w.iso from lenovo website, the kernel shows no more "mem" in /sys/power/state and also reports no ACPI S3 support in dmesg output.

So it looks like lenovo fixed the feature by removing it :-/

Also the image is not bootable (as is) from USB-stick.
However, upgrading using CD worked.

Please note that you might also need to load the "OS-Optimized" defaults in the Bios. You might also need to restore your bootloader afterwards.

At least the update also fixed a sound issue ;-)
Comment 87 RussianNeuroMancer 2016-12-20 21:52:57 UTC
Well, if Lenovo removed S3 then I guess S3 not implemented properly by BIOS. 

How suspend freeze working this days with Linux 4.9?

By the way, you can switch suspend to freeze mode permanently: https://www.freedesktop.org/software/systemd/man/sleep.conf.d.html
Comment 88 Tudor Protopopescu 2016-12-21 09:26:25 UTC
I have not updated the bios, but with the old one freeze half works for me, but only with the keyboard attached. 

If freeze is initiated without the keyboard attached, or if the keyboard is detached while frozen, then the computer cannot be resumed, even if the keyboard is reattached. The computer does not respond to pressing the start button, with or without keyboard, only keyboard input will unfreeze it. 

For what it is worth, the only kind of working power saving option in tablet mode is hibernate, but it hangs on resume every third or fourth try since the last reboot. At least the first hibernate after a reboot seems to work reliably, at least I have not yet seen hibernate fail to resume the first try after a reboot.
Comment 89 RussianNeuroMancer 2016-12-21 10:51:56 UTC
Okay, what about suspend/wakeup to/from freeze mode not by dock keyboard, but by any USB keyboard attached directly into tablet's USB port? Is this work?
Comment 90 Tudor Protopopescu 2016-12-22 07:00:31 UTC
Yes, this works too, but like with the dock, only if the usb keyboard is not unplugged and replugged during freeze, then the computer cannot be resumed. Freeze does not resume with just a usb mouse.
Comment 91 RussianNeuroMancer 2016-12-22 09:55:34 UTC
So essentially suspend and wakeup is working (in freeze mode). Problem is that power button is not supported, so it can not wakeup tablet. Also as I understand Linux "lost" dock keyboard once it detached in suspend, so when it attached back, dock keyboard can not wakeup tablet too. Is that correct?
Comment 92 Tudor Protopopescu 2016-12-22 10:33:38 UTC
Yes, that's right.
Comment 93 RussianNeuroMancer 2016-12-22 19:52:29 UTC
I forgot to ask, close/open lid also lead to successful suspend/resume?
Comment 94 Tudor Protopopescu 2016-12-23 11:38:03 UTC
Opening the lid does not resume freeze. However I am not sure how to test further. I have not looked at the settings in a while, but now I find that I no longer have a 'suspend' power setting option in my desktop (KDE 5).

Following your link from above I set SuspendMode=freeze and SuspendState=freeze in /etc/systemd/sleep.conf. To test the lid I tried to change the kde settings for the lid event, but 'suspend' is not one of the available options any longer, nor is it available from the regular desktop main menu. echo mem > /sys/power/state still works.

I may have done something to remove the suspend option from kde to prevent using it, but I cannot remember if I did, and what that might be. I'll keep looking.
Comment 95 yaplej 2017-01-07 19:26:57 UTC
Im having a similar issue with my new Latitude 7275 2-in-1.  If the screen goes to sleep after its timeout I cannot resume or get it to come back on.  Same if I close the folio/keyboard it goes off and I cannot get it back on.  Holding the power and doing a full reboot brings it back.
Comment 96 chris 2017-02-16 17:42:04 UTC
Dear all,

[There's hope; the "platform" might not be buggy after all; the bug
might be on Linux side (viz. fixable); Power Button Event is actually
taken into account by the "platform" during "echo mem >
/sys/power/state" while no physical keyboard is attached.]

I've recently acquired a Helix 20CH, with only plain "ultrabook"
Keyboard, so I won't be troubled whatsoever with any kind of "lid
close/lid open event".

Then there is the question of "suspend to disk/hibernation". This
issue has been discussed there:
https://bugs.freedesktop.org/show_bug.cgi?id=96526, and fixed there:
https://patchwork.freedesktop.org/patch/111587/
(https://bugs.debian.org/855055).
(Then, of course, my kernel is 4.10)

About the BIOS, I have installed the latest one, viz. of
2016/09/28. Actually it's weird, I'm not sure of the date, because
Lenovo have yet put another version, as of today...  Anyway, this is
the md5sum of the version I installed:
6dad6e304d5b31eaec63f76dabe4d7a7 n17ur45w.iso
(https://support.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-helix-series-laptops/thinkpad-helix-type-20cg-20ch/downloads/ds102026)
(I've used the CD iso + "geteltorito" + USB stick; see
https://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/.)

Now, I will only deal with: echo mem > /sys/power/state.  I was in the
process of verifying it doesn't work, when against all expectation, it
did work, somehow.

I've experimented only on a very narrow setting; I've repeated the
sequence enough time to have an accurate description; however I've got
no understanding of what's going on.

The setting is: no physical keyboard; "CellWriter"'s onscreen keyboard
for the minimal necessary interaction (Arrow Up to navigate in bash
history and Return to run the commands).

In order the wake the system up, only the power button. Beware that 6
seconds are sufficient for a shutdown; and a short press might not be
sufficient for the waking up purpose.

Originally I've configured KDE(5)'s Settings so that power button
triggers hibernation (no confirmation asked).

So, prior to the initial test, the computer might have been put in
hibernation state, without plain shutdown in between (not sure, but
possible).

Then I do:
echo mem > /sys/power/state (Ret. CellWriter, no phy. keyboard)

Then I press the power button for env. 2 seconds.

Then the computer turns back to life... And then automatically go into
hibernation!

Thrilled by that unexpected good behavior, I do that a couple of times.

Then I go into KDE's Settings and change the behavior of the power
button to "ask what to do".

Then I do:
echo mem > /sys/power/state

It might have worked once (viz. coming back to life with the pressing
of the power button)... But not twice!

OK, long story short:

echo disk > /sys/power/state
echo mem > /sys/power/state
echo disk > /sys/power/state
echo mem > /sys/power/state
echo disk > /sys/power/state
echo mem > /sys/power/state
.......
Works

echo disk > /sys/power/state
echo mem > /sys/power/state (does wake up w. Pow. Button)
echo mem > /sys/power/state (Doesn't wake up; Pow. Button shutdown necessary)
Works not!

Regards,
Chris
Comment 97 Tudor Protopopescu 2017-02-17 11:07:04 UTC
Unfortunately, I have not been able to reproduce this. Perhaps I have not followed the process exactly enough?

Here is what I did:

I was still using BIOS version 1.83, with kernel 4.9.rc3. I update the BIOS to version 1.91 (n17uj45w) (via the update utility since it would not work off the usb stick, though it booted and appeared to update). 

BIOS 1.91, kernel 4.9.rc3 results:

echo mem > /sys/power/state failed with an 'invalid operation' error. 'cat /sys/power/state' returned only 'freeze disk'.
Freeze still works as above (keyboard has to be and remain attached to resume), with the difference that now the led light stays on, rather than turns off.

I then updated the kernel to 4.10.rc7.

BIOS 1.91, kernel 4.10.rc7 results:

'cat /sys/power/state' returns 'freeze mem disk'. 'echo mem > /sys/power/state' suspends except now the led light stays on rather than pulsing.

So, I set KDE power settings to hibernate when power button is pressed, then detached the tablet, and entered 'echo mem > /sys/power/state' using Onboard, rather than CellWriter. I held the power button down for 2-3 seconds, but the tablet did not wake up and go into hibernation. I tried this several times and got the same result. I also tried it with no keyboard attached from boot, but that made no difference for me. 

One difference might be that I have a model 20CG rather than 20CH? Maybe it is something distribution specific? I am using openSUSE Tumbleweed. What does your /etc/systemd/sleep.conf look like?

Regardless it is encouraging to know that this might still be fixable after all!
Comment 98 RussianNeuroMancer 2017-02-17 13:35:39 UTC
> entered 'echo mem > /sys/power/state' using Onboard, rather than CellWriter.
> I held the power button down for 2-3 seconds, but the tablet did not wake up
> and go into hibernation

So you send tablet to S3, then press power button, and tablet goes to S4?
Did you able to wake up from S3 with power button?
Comment 99 chris 2017-02-17 15:57:50 UTC
(In reply to Tudor Protopopescu from comment #97)

[I use "platform*" to designate motherboard + EFI/BIOS/firmware,
following the usage in:
Suspend-to-RAM in Linux. Leonard Brown. Rafael J. Wysocki.
https://www.landley.net/kdocs/ols/2008/ols2008v1-pages-39-52.pdf

Also, not very sure about S0, S1, S2, S3, S4, S5
(https://www.kernel.org/doc/Documentation/power/states.txt)
So I might use, perhaps wrongly, "STR*" aka. Suspend to Ram.]

> BIOS 1.91, kernel 4.10.rc7 results:
> 
> 'cat /sys/power/state' returns 'freeze mem disk'. 'echo mem >
> /sys/power/state' suspends except now the led light stays on rather than
> pulsing.
> 
> So, I set KDE power settings to hibernate when power button is pressed, then
> detached the tablet, and entered 'echo mem > /sys/power/state' using
> Onboard, rather than CellWriter. I held the power button down for 2-3
> seconds, but the tablet did not wake up and go into hibernation.

I might be mistaken, but what I see here, is that:
- Power Button event is taken into account,
- by the "platform" (I mean motherboard + EFI/BIOS/firmware*),
- during "echo mem > /sys/power/state" (STR?).
- And that, without physical keyboard!

IMO, that definitely shows the problem is fixable.

Now the system might have:
waked up from "echo mem > /sys/power/state" (STR),
then gone, very quickly (without leaving you enough time to notice the
system has even been awaken), into hibernation state (STD), (because this
is the behavior you chosed in KDE's Settings?).
(I don't think the platform* itself, could be responsible for this,
"secondary" behavior)

This is why, after this first, and fortuitous, experiment,
I did this alternate experiment:

First, remove the association "power button => hibernation",
in KDE's Settings;

Then: (with no physical keyboard)

echo disk > /sys/power/state;
Wake the system with Pow. Button;
(Here there is no problem, because it's a full fledged booting process,
only with an additional disk image).

Then (still no keyboard):

echo mem > /sys/power/state;
Wake the system with Pow. Button;
This is where it should wake up, and then "not" go immediately
into hibernation, because this behavior has been removed from
the KDE's Settings.

etc.

echo disk > /sys/power/state
echo mem > /sys/power/state
echo disk > /sys/power/state
echo mem > /sys/power/state

This worked for me.

Note:
echo mem > /sys/power/state
echo mem > /sys/power/state
echo mem > /sys/power/state
Didn't work;
The system just didn't respond, in any visible way,
to the power button event.
Power Button hard shutdown necessary.

> One difference might be that I have a model 20CG rather than 20CH? Maybe it
> is something distribution specific? I am using openSUSE Tumbleweed. What
> does your /etc/systemd/sleep.conf look like?

/etc/systemd/sleep.conf: No such file or directory

> Regardless it is encouraging to know that this might still be fixable after
> all!

I think your experiment was successful:
Your system, did actually react to Power Button event,
that, in STR (suspend to ram state),
and that, without physical keyboard attached.

We must find someone that can tell us what can possibly be the difference
between the two sequences:
STR, STR, STR,
and:
STD, STR, STD, STR

(BTW, I'm using Debian Sid, with the 4.10 experimental kernel,
https://bugs.debian.org/855055)

Thanks,
Chris
Comment 100 chris 2017-02-17 16:05:56 UTC
(In reply to RussianNeuroMancer from comment #98)
> > entered 'echo mem > /sys/power/state' using Onboard, rather than
> CellWriter.
> > I held the power button down for 2-3 seconds, but the tablet did not wake
> up
> > and go into hibernation
> 
> So you send tablet to S3, then press power button, and tablet goes to S4?
> Did you able to wake up from S3 with power button?

IMO, it is not logically possible that the tablet goes from S3 (STR),
to S4 (STD) (that following the Power Button Event),
without passing the control to the Linux Kernel in between.

Thanks,
Chris
Comment 101 Tudor Protopopescu 2017-02-18 08:10:09 UTC
Created attachment 254817 [details]
Dmesg after successful wake up from suspend
Comment 102 Tudor Protopopescu 2017-02-18 08:27:22 UTC
I can confirm this works, and can reliably reproduce it. So it is now possible for the helix to respond to power button events after suspend. 

I misunderstood the process  above and so was not doing things in the right order. (I was expecting that with KDE power button set to 'hibernate' if one suspends then pressing the button would wake up the tablet from suspend and immediately initiate a hibernate. That did not appear to work, in suspend the led stays on, in hibernate the light is off. In what I tried the light stayed on the whole time, suggesting that the tablet did not go from suspend to hibernate.)

Just to be clear these are my settings and what I do:

BIOS 1.91, kernel 4.10.rc7. The KDE power button setting seems to make no essential difference. I have 'ask what to do'. The process also works with keyboard attached, and the system can be woken up from suspend by pressing a key on the keyboard, as well as the power button, opening the lid does not wake up the tablet.

In a console:

1. echo disk > /sys/power/state

2. Wake up the system from hibernate

3. echo mem > /sys/power/state

4. Wake up the system from suspend, with power button or keyboard press. 

I can repeat this sequence reliably.

Setting the power button to 'hibernate' and pressing the button at step 1 also allows step 4. Hibernating from a menu, on KDE at least, for step 1, does not allow step 4.  Doing any other order does not work either, so 1-2-1-2-3 does not allow 4. 

Attaching and detaching the keyboard at any step does not seem to make a difference.

I've attached dmesg output; from boot and one cycle of steps 1-4.  

Regarding freeze, with the new kernel or bios, the freeze seems not as deep as before. Not only does the led stay on, when before it would turn off, now the tablet emits a faint sound, so something in there is still working, and stays as warm as it does when on and idling. Before it would be completely silent and cold, just like when it is turned off.

I've attached another dmesg output for this too; from boot, freeze and wake up.
Comment 103 Tudor Protopopescu 2017-02-18 08:28:33 UTC
Created attachment 254819 [details]
Dmesg after wake up from freeze
Comment 104 chris 2017-02-18 13:24:07 UTC
Could we say that we agree on the following specifics:

[abstract: interaction between "echo mem > /sys/power/state" and
"echo mem > /sys/power/state"]

(STR = suspend to ram = echo mem > /sys/power/state;
 STD = hibernation    = echo disk > /sys/power/state)

1- With keyboard attached, and never detached during the process,
waking up from STR, through pressing keyboard key, is always successful.

2- When keyboard is detached, it is yet possible to wake up from STR,
through pressing of the power button, but that only through a complicated
and specific sequence of Suspend to Disk and Suspend to Ram.

3- The behavior of "2" is always reproducible.

4- The invocation of "echo mem > /sys/power/state", outside of the
specific sequence, and with no keyboard attached, results in the computer
being stuck in STR state, with no way to bring it back, other than "hard"
shutdown with the Power Button.

5- There is an interaction between "echo mem > /sys/power/state" and
"echo disk > /sys/power/state": the invocation of the second allowing
the success of the first (even without keyboard); though the plain
and unprepared invocation of the first result in a failure to wake up
the system.
Comment 105 chris 2017-02-18 13:38:16 UTC
(In reply to chris from comment #104)
> Could we say that we agree on the following specifics:
> 
> [abstract: interaction between "echo mem > /sys/power/state" and
> "echo mem > /sys/power/state"]

[abstract: interaction between "echo mem > /sys/power/state" and
"echo disk* > /sys/power/state"]

> 
> (STR = suspend to ram = echo mem > /sys/power/state;
>  STD = hibernation    = echo disk > /sys/power/state)
> 
> 1- With keyboard attached, and never detached during the process,
> waking up from STR, through pressing keyboard key, is always successful.
> 
> 2- When keyboard is detached, it is yet possible to wake up from STR,
> through pressing of the power button, but that only through a complicated
> and specific sequence of Suspend to Disk and Suspend to Ram.
> 
> 3- The behavior of "2" is always reproducible.
> 
> 4- The invocation of "echo mem > /sys/power/state", outside of the
> specific sequence, and with no keyboard attached, results in the computer
> being stuck in STR state, with no way to bring it back, other than "hard"
> shutdown with the Power Button.
> 
> 5- There is an interaction between "echo mem > /sys/power/state" and
> "echo disk > /sys/power/state": the invocation of the second allowing
> the success of the first (even without keyboard); though the plain
> and unprepared invocation of the first result in a failure to wake up
> the system.
Comment 106 Tudor Protopopescu 2017-02-19 07:43:20 UTC
(In reply to chris from comment #104)
> Could we say that we agree on the following specifics:
> 
> [abstract: interaction between "echo mem > /sys/power/state" and
> "echo mem > /sys/power/state"]
> 
> (STR = suspend to ram = echo mem > /sys/power/state;
>  STD = hibernation    = echo disk > /sys/power/state)
> 
> 1- With keyboard attached, and never detached during the process,
> waking up from STR, through pressing keyboard key, is always successful.

Yes, and it is also possible if the keyboard is detached and reattached. I detached the keyboard after STR and reattached and resumed both with keyboard input and power button. The presence of the keyboard seems not to influence the process at any stage. 


> 
> 2- When keyboard is detached, it is yet possible to wake up from STR,
> through pressing of the power button, but that only through a complicated
> and specific sequence of Suspend to Disk and Suspend to Ram.

Yes. But this seems to imply that this specific sequence is not needed if the keyboard is attached. I found the specific STD-STR sequence has to be followed with keyboard too. Basically, the sequence is necessary no matter what, the keyboard is optional. (This is an improvement on freeze since that only resumes if the keyboard is always attached).

> 
> 3- The behavior of "2" is always reproducible.

Yes.

> 
> 4- The invocation of "echo mem > /sys/power/state", outside of the
> specific sequence, and with no keyboard attached, results in the computer
> being stuck in STR state, with no way to bring it back, other than "hard"
> shutdown with the Power Button.

Yes, but keyboard does not seem to matter; not following the sequence leads to not being able to resume regardless of keyboard presence. 

> 
> 5- There is an interaction between "echo mem > /sys/power/state" and
> "echo disk > /sys/power/state": the invocation of the second allowing
> the success of the first (even without keyboard); though the plain
> and unprepared invocation of the first result in a failure to wake up
> the system.

Yes. It seems that if these can be disentangled STR would work as expected.
Comment 107 chris 2017-02-19 13:17:46 UTC
(In reply to Tudor Protopopescu from comment #106)

"comment #106" seems a clean statement.

It seems we have a clean bug now, and the status could change
to CONFIRMED.

Latest BIOS, latest Kernel, 2 similar but different computers,
identical sequences,

reproducible: always.
Comment 108 Zhang Rui 2017-03-27 03:24:39 UTC
so,
1. with keyboard attached, everything works well
2. STR breaks, only if with keyboard detached, even detached before boot
3. STR problem can be worked around, by a special sequence(issueing a STD before STR)
right?
Do you know what the keyboard device and driver are, in kernel?
Comment 109 Tudor Protopopescu 2017-03-27 10:27:36 UTC
(In reply to Zhang Rui from comment #108)
> so,
> 1. with keyboard attached, everything works well

No, STR does not work normally with or without keyboard. The computer resumes from STR only if the sequence of hibernate/suspend outlined above is followed. The keyboard makes no difference. Attaching or detaching the keyboard at any stage of the hibernate/suspend sequence does not effect whether the computer does or does not resume from STR. Resuming from STR depends on only whether one has followed the sequence correctly. 

> 2. STR breaks, only if with keyboard detached, even detached before boot

No, STR is broken even if the keyboard is attached the whole time.

The presence of the keyboard makes a difference only for freeze (echo freeze > /sys/power/state). The computer can be resumed from freeze only if the keyboard is attached the whole time, i.e. attached when freeze is initiated, and stays attached until resumed; the computer only resumes from freeze with keyboard input. If freeze is initiated without the keyboard, or if it is detached while frozen, and reattached, the computer will not resume. 


> 3. STR problem can be worked around, by a special sequence(issueing a STD
> before STR)
> right?

Yes, but the workaround is necessary if the keyboard is attached too.

> Do you know what the keyboard device and driver are, in kernel?

Here is the output of `usb-devices':

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=17ef ProdID=6047 Rev=03.30
S:  Manufacturer=Lenovo
S:  Product=ThinkPad Compact USB Keyboard with TrackPoint
C:  #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid


And here is the output of openSUSE's yast "hardware info" for the keyboard:

41: USB 00.0: 10800 Keyboard
  [Created at usb.122]
  Unique ID: DHyf.y_GigfJU6hB
  Parent ID: 2UT6.acAEQgOGgM2
  SysFS ID: /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.4/1-3.4:1.0
  SysFS BusID: 1-3.4:1.0
  Hardware Class: keyboard
  Model: "Lenovo ITE Device(8595)"
  Hotplug: USB
  Vendor: usb 0x17ef "Lenovo"
  Device: usb 0x6067 "ITE Device(8595)"
  Driver: "usbhid"
  Driver Modules: "usbhid"
  Device File: /dev/input/event20
  Device Files: /dev/input/event20, /dev/input/by-id/usb-ITE_Tech._Inc._ITE_Device_8595_-event-kbd, /dev/input/by-path/pci-0000:00:14.0-usb-0:3.4:1.0-event-kbd
  Device Number: char 13:84
  Speed: 12 Mbps
  Module Alias: "usb:v17EFp6067d0000dc00dsc00dp00ic03isc01ip01in00"
  Driver Info #0:
    XkbRules: xfree86
    XkbModel: pc104
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #42 (Hub)


Let me know if you need any other info.
Comment 110 Tudor Protopopescu 2017-05-23 11:10:17 UTC
Unfortunately the process above no longer works for me.

I updated the bios, to version 1.93, and the kernel, to 4.11.0 (4.11.0-3g98d6a9a-default from openSUSE Tumbleweed repo), and now the hibernate-suspend sequence no longer works. Specifically the computer cannot be resumed from suspend by pressing the power button. 

However, ``echo mem > /sys/power/state'' does not in fact suspend to ram (STR). STR is not available: ``cat /sys/power/mem_sleep'' returns only `s2idle', so ``echo mem > /sys/power/state'' in fact only initiates Suspend-To-Idle (freeze), rather than STR proper. 

The computer can be woken up only with keyboard input, and only if the keyboard is attached when initiating freeze and if it stays attached while frozen.

I did not check the contents of  /sys/power/mem_sleep with the older bios and kernel, but the dmesg output I uploaded shows that ``echo mem > /sys/power/state'' initiates freeze/Suspend-To-Idle, rather than STR, if I understand it correctly.

So it seems that the hibernate-suspend sequence above did not get STR to work, but rather that it got Suspend-To-Idle/freeze to work better. Specifically, the sequence enabled waking up from freeze via the power button, which did not work before and no longer works.
Comment 111 RussianNeuroMancer 2017-06-14 11:43:52 UTC
Is anyone from Intel could look into this once again?

As I understand tablet should be able to wakeup by power button and by home button (as in Windows).
Also keyboard should be able wakeup tablet even if keyboard was dateched and then attached in S0ix.

What info is needed to resolve this?
Comment 112 Zhang Rui 2017-06-16 03:15:55 UTC
(In reply to RussianNeuroMancer from comment #111)
> Is anyone from Intel could look into this once again?

yes. I'd like to.
can you confirm the new symptom in comment #110?
Comment 113 Zhang Rui 2017-06-16 03:22:33 UTC
(In reply to Tudor Protopopescu from comment #110)
> Unfortunately the process above no longer works for me.
> 
> I updated the bios, to version 1.93, and the kernel, to 4.11.0
> (4.11.0-3g98d6a9a-default from openSUSE Tumbleweed repo), and now the
> hibernate-suspend sequence no longer works. Specifically the computer cannot
> be resumed from suspend by pressing the power button. 
> 
> However, ``echo mem > /sys/power/state'' does not in fact suspend to ram
> (STR). STR is not available: ``cat /sys/power/mem_sleep'' returns only
> `s2idle', so ``echo mem > /sys/power/state'' in fact only initiates
> Suspend-To-Idle (freeze), rather than STR proper. 
> 

are you able to downgrade your BIOS to previous version?
please attach the acpidump output with BIOS v1.93.

Any possible explanation of this is that, S3 is not well supported on this platform.
Say, windows only uses S0i3 on this platform, and S3 is "supported" in BIOS but it actually never gets well tested before. And Lenovo is aware of this problem and removes the S3 support in BIOS in its latest BIOS.

If there is no S3 support in latest BIOS , I think we should focus on the STI problems only. To confirm this,
either I can check this via the acpidump you attached,
or you can confirm this by search this line in dmesg output,
      ACPI: (supports S0 S4 S5)
If there is S3 support, it will be listed here.
Comment 114 Zhang Rui 2017-06-16 03:23:23 UTC
s/Any possible explanation/A possible explanation
Comment 115 Tudor Protopopescu 2017-06-16 16:19:37 UTC
I downgraded the BIOS back to 1.91 and the hibernate-freeze sequence works there (with kernel 4.11.0). I attach an acpidump with bios 1.91, dmesg output has "ACPI: (supports S0 S4 S5)", cat /etc/power/mem_sleep yields only "s2idle". 

In order to get the acpidump from bios version 1.93 I re-upgraded, and the hibernate-freeze sequence works. I think the difference from before (say comment 106 above) is that how hibernate is initiated now makes a difference. 

The computer now wakes up from freeze only if hibernate is initiated from the terminal; this is with either bios version 1.91 or 1.93. Previously, the sequence also worked if hibernate was initiated by configuring the power button to hibernate, or to prompt what to do, now neither option allows freeze to be resumed with the power button. 

That is: after doing in a terminal "echo disk > /sys/power/state", resuming and then "echo mem > /sys/power/state" the computer can be resumed by pressing the power button. This can be done with or without the keyboard, the keyboard can be detached or reattached during freeze and the computer can be resumed. Doing two "echo mem > /sys/power/state" in a row does not allow the computer to resume from freeze with the power button; only keyboard input  will work, and only if the keyboard was attached before freeze and not detached during freeze.

I notice also that resuming from "echo disk > /sys/power/state" brings up the grub menu on resume. Resuming from hibernate initiated by the power button, or the power options menu (in KDE), does not bring up the grub menu, but just resumes into linux.

I attach acpidump for both bios 1.91 and 1.93. 

For what it is worth; suspend (or sleep) works fine on Windows, the led shuts off and much less battery is consumed than in linux with freeze, so under some conditions the platform is capable of proper STR.
Comment 116 Tudor Protopopescu 2017-06-16 16:20:25 UTC
Created attachment 257025 [details]
ACPI Dump BIOS 1.91
Comment 117 Tudor Protopopescu 2017-06-16 16:20:56 UTC
Created attachment 257027 [details]
ACPI Dump BIOS 1.93
Comment 118 Zhang Rui 2017-07-01 07:33:07 UTC
(In reply to Tudor Protopopescu from comment #115)
> I downgraded the BIOS back to 1.91 and the hibernate-freeze sequence works
> there (with kernel 4.11.0). I attach an acpidump with bios 1.91, dmesg
> output has "ACPI: (supports S0 S4 S5)", cat /etc/power/mem_sleep yields only
> "s2idle". 

So there is no STR on this platform from the beginning?

I'm confused because I thought we're talking about suspend to mem (ACPI S3) issues.

@Tom Li
please confirm there is no S3 support on your platform as well.

I think we need to start a new thread with clear statement that all of this is about suspend to freeze mode, or s2idle.
Comment 119 Tudor Protopopescu 2017-07-01 08:49:16 UTC
(In reply to Zhang Rui from comment #118)
> (In reply to Tudor Protopopescu from comment #115)
> > I downgraded the BIOS back to 1.91 and the hibernate-freeze sequence works
> > there (with kernel 4.11.0). I attach an acpidump with bios 1.91, dmesg
> > output has "ACPI: (supports S0 S4 S5)", cat /etc/power/mem_sleep yields
> only
> > "s2idle". 
> 
> So there is no STR on this platform from the beginning?
> 
> I'm confused because I thought we're talking about suspend to mem (ACPI S3)
> issues.

STR definitely used to be on this platform, at some point in the last year it seems to have been taken out. But when I got the machine suspend and freeze did different things - it was possible to resume from freeze and not from suspend.

However, for the hibernate-suspend sequence that the power button works with (comments 98 and later) we may have indeed been talking about resuming from freeze only, since STR had already been taken out of the platform by then. That is true of my platform since I was testing with bios 1.91.
Comment 120 Zhang Rui 2017-09-11 05:59:51 UTC
TBH, I think the discussion in this thread becomes misleading, especially after S3 got removed from BIOS.

I will close this bug report.

Let's start a new thread, with detailed information about the problems with Suspend-to-Freeze only.
Comment 121 Tudor Protopopescu 2017-09-16 09:06:13 UTC
It may be of interest to some watching this bug that the problems with STI have largely been fixed as of 4.13.1. Resuming from STI with the power button now works pretty much as expected, with one exception: STI fails if the keyboard is detached and reattached.

New bug regarding STI submitted here: https://bugzilla.kernel.org/show_bug.cgi?id=196957

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