Bug 100171
|
Description
Tom Li
2015-06-20 17:33:02 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. Since it still presents on Linux 4.1, I'm going to start debugging and I'll post my results soon. Please attach its acpidump and dmesg. ping Sorry for the delay. I can also confirmed with Linux 4.2. 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.
Created attachment 187001 [details]
dmesg from Linux 4.2
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 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.
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? > 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. (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. > 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. (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. (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? 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. I've just tested with rtcwake and the system doesn't resume. Resume from hibernation does work however. 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. 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). 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... (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... 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/ 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. Does Lenovo have a support forum? Post the problem there may catch their eyes. (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. 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 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. 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).
Created attachment 202481 [details]
dmesg without i915
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. (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. (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. 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. 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. I am affected by this bug too. freeze does work, but only with keyboard attached. In tablet mode, nothing happens. 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? (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. 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. 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 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. 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). 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. 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. :) 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. 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 (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? (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. (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. 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 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. (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? 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. (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? 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?
(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. (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. > 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.
(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. 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. > 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? > (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. (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 then ignore this one and attach the others. ping... 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.
(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". 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. Created attachment 222321 [details]
Test Results of suspend to mem with pm_test set to core
Created attachment 222341 [details]
rtc_trace - dmesg after reboot after failed suspend to mem
(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. (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. 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.
Created attachment 225921 [details]
Dmesg after pm_test set to core
(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. 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 Installed kernel 4.8.0-rc1, intel_vbtn loaded. Unfortunately it did not make a difference for me. (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. 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 ping (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. Created attachment 241621 [details]
Dmesg after echo core > /sys/power/pm_test
Created attachment 241631 [details]
Dmesg after echo mem > /sys/power/state
(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. Hi, Chen Some additional info is needed? (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. 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 ;-) 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 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. 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? 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. 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? Yes, that's right. I forgot to ask, close/open lid also lead to successful suspend/resume? 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. 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. 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 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! > 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?
(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 (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 Created attachment 254817 [details]
Dmesg after successful wake up from suspend
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. Created attachment 254819 [details]
Dmesg after wake up from freeze
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. (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. (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. (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. 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? (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. 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. 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? (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? (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. s/Any possible explanation/A possible explanation 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. Created attachment 257025 [details]
ACPI Dump BIOS 1.91
Created attachment 257027 [details]
ACPI Dump BIOS 1.93
(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. (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. 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. 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 |