Bug 153101 - Dell Venue 11 Pro 7140 get suspend again while first wakeup, normally wakeup on second try
Summary: Dell Venue 11 Pro 7140 get suspend again while first wakeup, normally wakeup ...
Status: RESOLVED DUPLICATE of bug 102281
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: acpi_power-sleep-wake
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-14 15:50 UTC by RussianNeuroMancer
Modified: 2016-12-22 02:07 UTC (History)
4 users (show)

See Also:
Kernel Version: 4.7.0
Tree: Mainline
Regression: No


Attachments
dmesg (59.37 KB, application/octet-stream)
2016-08-14 15:50 UTC, RussianNeuroMancer
Details
wakeup devices (768 bytes, text/plain)
2016-08-15 07:34 UTC, RussianNeuroMancer
Details
acpidump (585.33 KB, application/octet-stream)
2016-08-23 03:51 UTC, RussianNeuroMancer
Details
dmesg with patched kernel (63.14 KB, application/octet-stream)
2016-08-23 07:32 UTC, RussianNeuroMancer
Details
dmesg systemd debug (543.96 KB, application/octet-stream)
2016-08-23 10:00 UTC, RussianNeuroMancer
Details
wakeup content from /bash/init (768 bytes, application/octet-stream)
2016-09-26 09:53 UTC, RussianNeuroMancer
Details
wakeup content from normal boot (768 bytes, application/octet-stream)
2016-09-26 09:53 UTC, RussianNeuroMancer
Details

Description RussianNeuroMancer 2016-08-14 15:50:09 UTC
Hello!
First of all, due to issues with suspend to RAM I using suspend freeze configured via systemd.
Also, after successful wakeup next suspend again lead to same behaviour, so two wakeups required to get tablet awake after warm boot and after previous suspend/wakeup cycle.

dmi.sys.vendor: Dell Inc.
dmi.product.name: Venue 11 Pro 7140

dmesg is attached. Tested kernels 4.4-4.8, and result roughly the same (sometime more tries to wakeup tablet is required).
Comment 1 RussianNeuroMancer 2016-08-14 15:50:33 UTC
Created attachment 228611 [details]
dmesg
Comment 2 RussianNeuroMancer 2016-08-14 16:01:04 UTC
More info:
Wakeup via tablet powerbutton doesn't work.
Wakeup via folio cover doesn't work: https://bugzilla.kernel.org/show_bug.cgi?id=150701
Attached keyboard was used to test wake up from suspend.
Comment 3 Zhang Rui 2016-08-15 07:05:18 UTC
please attach the content of /proc/acpi/wakeup
Comment 4 RussianNeuroMancer 2016-08-15 07:34:27 UTC
Created attachment 228681 [details]
wakeup devices

/proc/acpi/wakeup output is attached.
Comment 5 Lv Zheng 2016-08-23 03:18:35 UTC
(In reply to RussianNeuroMancer from comment #0)
> Hello!
> First of all, due to issues with suspend to RAM I using suspend freeze
> configured via systemd.
> Also, after successful wakeup

What does the wakeup mean here?
Wakeup via power button? Or wakeup via folio cover?


> next suspend again lead to same behaviour, so
> two wakeups required to get tablet awake after warm boot and after previous
> suspend/wakeup cycle.

Can you explain this behavior with more detailed information?
> 
> dmi.sys.vendor: Dell Inc.
> dmi.product.name: Venue 11 Pro 7140
> 
> dmesg is attached. Tested kernels 4.4-4.8, and result roughly the same
> (sometime more tries to wakeup tablet is required).

[  116.504404] PM: Preparing system for sleep (freeze)
...
[  116.809616] PM: suspend-to-idle

What's the triggering source of the above "suspend-to-idle"?

[  153.654185] PM: resume from suspend-to-idle
...
[  154.884252] PM: Finishing wakeup.
[  154.884255] Restarting tasks ... done.

What's the triggering source of the above "resume-from-idle"?

...
[  160.567255] PM: Syncing filesystems ... done.
[  160.590497] PM: Preparing system for sleep (freeze)
...
[  160.717691] PM: suspend-to-idle

What's the triggering source of the above "suspend-to-idle"?

[  182.608191] PM: resume from suspend-to-idle
...
[  183.834008] PM: Finishing wakeup.
[  183.834010] Restarting tasks ... done.

What's the triggering source of the above "resume-from-idle"?

...


Thanks
Lv
Comment 6 Lv Zheng 2016-08-23 03:29:48 UTC
Please also upload acpidump output here.
Comment 7 RussianNeuroMancer 2016-08-23 03:44:18 UTC
> What does the wakeup mean here?
In this particular case - wakeup from keyboard attached via USB (not dock).
Linux 4.4 patched to make use of dv11p-tablet driver behave not better, so with power button or folio cover more then one wakeup attempt usually required. 

> Can you explain this behavior with more detailed information?
Warm boot:
Press suspend button, tablet gets suspended, press some button on keyboard to wakeup, tablet wakeup and then suspend on it's own, again press some button on keyboard, tablet is resume normal work.
Next try in same session, without reboot or power cycle lead to same behaviour:
I press suspend button keyboard, tablet suspend, press some keyboard button to wakeup, tablet wakeup and suspend again, I again press some keyboard button to wakeup, then tablet resume normal work.

My point here is that behaviour is the same after warm boot or after suspend.

> What's the triggering source of the above "suspend-to-idle"?
I press suspend button on keyboard.

> What's the triggering source of the above "resume-from-idle"?
I press some button on keyboard.

> What's the triggering source of the above "suspend-to-idle"?
I don't know. Not me.

> What's the triggering source of the above "resume-from-idle"?
I press some button on keyboard.
Comment 8 RussianNeuroMancer 2016-08-23 03:51:10 UTC
Created attachment 229771 [details]
acpidump

> Please also upload acpidump output here.
Attached.
Comment 9 Lv Zheng 2016-08-23 04:34:55 UTC
(In reply to RussianNeuroMancer from comment #7)
Thanks for the detailed description.

> > What's the triggering source of the above "suspend-to-idle"?
> I don't know. Not me.

I'll help to figure this out.
Please wait, and I'll submit a debugging patch to do this.

Thanks
Lv
Comment 10 Chen Yu 2016-08-23 04:56:07 UTC
Please test with init=/bin/bash appended in the grub, is the issue still reproduced?
Comment 11 Chen Yu 2016-08-23 04:56:35 UTC
Index: for_debug/kernel/power/suspend.c
===================================================================
--- for_debug.orig/kernel/power/suspend.c
+++ for_debug/kernel/power/suspend.c
@@ -402,6 +402,9 @@ int suspend_devices_and_enter(suspend_st
 	int error;
 	bool wakeup = false;
 
+	printk("Current(%d,%s),on cpu:%d,is trying to suspend the system\n",
+		current->pid, current->comm, smp_processor_id());
+	dump_stack();
 	if (!sleep_state_supported(state))
 		return -ENOSYS;
Comment 12 Lv Zheng 2016-08-23 05:06:27 UTC
Since we needn't to figure out which is the triggering source of the 2 resume-from-idle, let me reset the bug assignee.
Comment 13 RussianNeuroMancer 2016-08-23 07:29:54 UTC
> Please test with init=/bin/bash appended in the grub, is the issue still
> reproduced?
I wasn't able to put system into suspend freeze state from this console. "systemctl suspend" won't work and after "pm-suspend" tablet doesn't react on keyboard (with Linux 4.7) or powerbutton (with patched Linux 4.4).
Comment 14 RussianNeuroMancer 2016-08-23 07:32:35 UTC
Created attachment 229791 [details]
dmesg with patched kernel

dmesh of suspend/resume cycle with patched kernel.
Comment 15 RussianNeuroMancer 2016-08-23 07:33:22 UTC
New dmesg from kernel with patch from Comment 11.
Comment 16 Lv Zheng 2016-08-23 08:19:14 UTC
	Line 827: [   64.640029] Current(3744,systemd-sleep),on cpu:0,is trying to suspend the system
	Line 876: [   97.197902] Current(3998,systemd-sleep),on cpu:1,is trying to suspend the system

Looks like the both suspend operations are triggered by systemd-sleep.
The 1st suspend is apparently a result of suspend button event.
So for the 2nd suspend, we need to know what has caused the systemd to trigger the suspend operation.
I don't know how can we debug systemd, can you try to ask questions in systemd community for help?

For kernel, could you also try a known quirk:
button.lid_init_state=open

Thanks
Lv
Comment 17 Lv Zheng 2016-08-23 08:32:10 UTC
Please try comment #10, booting your kernel with init=/bin/bash (in order not to start systemd).

After booting to the bash, please start acpid with "acpid -f -d -d -d -l", then start acpi_listen with "acpi_listen".
Then please help to split the log entries for us using 1st suspend/1st resume and 2nd suspend/2nd resume (if any) according to your observation (I hope the both tools can have timestamp in their outputs...)
Then upload the output of the 2 commands here.

Thanks
Lv
Comment 18 RussianNeuroMancer 2016-08-23 10:00:55 UTC
Created attachment 229811 [details]
dmesg systemd debug

> we need to know what has caused the systemd to trigger the suspend operation
dmesg with systemd debug options is attached.
Comment 19 RussianNeuroMancer 2016-08-23 10:04:01 UTC
> For kernel, could you also try a known quirk: button.lid_init_state=open
Tried this, doesn't help, behaviour is the same.

> Please try comment #10, booting your kernel with init=/bin/bash (in order not
> to start systemd).
Unfortunately, I doesn't know how to trigger "suspend freeze" mode here. "systemctl suspend" doesn't work here, and "pm-suspend" lead to un-wakeup-able state (maybe because of S3 issues that hardware have (like Helix 2 for example) maybe for some other reason).

If there is way to trigger "suspend freeze" mode from "init=/bin/bash" console - please let me know how to do that.
Comment 20 Chen Yu 2016-08-23 10:06:36 UTC
(In reply to RussianNeuroMancer from comment #19)
> > For kernel, could you also try a known quirk: button.lid_init_state=open
> Tried this, doesn't help, behaviour is the same.
> 
> > Please try comment #10, booting your kernel with init=/bin/bash (in order
> not to start systemd).
> Unfortunately, I doesn't know how to trigger "suspend freeze" mode here.
> "systemctl suspend" doesn't work here, and "pm-suspend" lead to
> un-wakeup-able state (maybe because of S3 issues that hardware have (like
> Helix 2 for example) maybe for some other reason).
> 
> If there is way to trigger "suspend freeze" mode from "init=/bin/bash"
> console - please let me know how to do that.

echo freeze > /sys/power/state
Comment 21 RussianNeuroMancer 2016-08-23 10:32:57 UTC
> I don't know how can we debug systemd, can you try to ask questions in
> systemd community for help?
Is I still need to do this or provided log from comment #18 is enough?

> echo freeze > /sys/power/state
How I forgot this... :)

Anyway, I tried to echo freeze > /sys/power/state, tablet freeze successfully (home button react with vibration, so it doesn't S3 or powered off) but I still can't wake up via keyboard, like in comment #13.
Comment 22 Lv Zheng 2016-08-24 02:46:28 UTC
(In reply to RussianNeuroMancer from comment #21)
> > I don't know how can we debug systemd, can you try to ask questions in
> systemd community for help?
> Is I still need to do this or provided log from comment #18 is enough?

Your 2nd suspend was caused by systemd.
Without debugging systemd, can we know the cause?
So it is required.

We could include Bastien Nocera, he can help us to check the cause of the 2nd suspend.

> 
> > echo freeze > /sys/power/state
> How I forgot this... :)
> 
> Anyway, I tried to echo freeze > /sys/power/state, tablet freeze
> successfully (home button react with vibration, so it doesn't S3 or powered
> off) but I still can't wake up via keyboard, like in comment #13.

These 2 comments are conflict:
I still can't wake up via keyboard
  ^^^^^^^^^^^^^^^^^^^     ^^^^^^^^
press some button on keyboard to wakeup, tablet wakeup
                     ^^^^^^^^            ^^^^^^^^^^^^^

Please explain.

Thanks
Comment 23 Lv Zheng 2016-08-24 02:47:28 UTC
Ping Bastien:
Please help us to figure out the trigger of the 2nd suspend.

Thanks in advance!
Lv
Comment 24 RussianNeuroMancer 2016-08-24 03:40:17 UTC
> Please explain.
Wakeup via keyboard works on normal launch, with systemd, gdm, Gnome Shell, etc.
Wakeup via keyboard doesn't work with init=/bin/bash (from S3 or from suspend freeze - doesn't work any way).
Comment 25 Lv Zheng 2016-08-29 07:18:02 UTC
(In reply to RussianNeuroMancer from comment #24)
> > Please explain.
> Wakeup via keyboard works on normal launch, with systemd, gdm, Gnome Shell,
> etc.
> Wakeup via keyboard doesn't work with init=/bin/bash (from S3 or from
> suspend freeze - doesn't work any way).

I don't know how can there be differences between the different userspaces.
Could you upload /proc/acpi/wakeup outputs for the 2 different launches here?
Let's see if some userspace tools have tuned the wakeup devices.

Thanks
Lv
Comment 26 RussianNeuroMancer 2016-09-26 09:53:01 UTC
Created attachment 239751 [details]
wakeup content from /bash/init
Comment 27 RussianNeuroMancer 2016-09-26 09:53:46 UTC
Created attachment 239761 [details]
wakeup content from normal boot
Comment 28 RussianNeuroMancer 2016-09-26 10:00:25 UTC
Sorry for delay, requested info uploaded.
There is relevant comment: https://bugzilla.kernel.org/show_bug.cgi?id=102281#c69

I don't know if Alexander tested wakeup with both of systemd suspend handling and Gnome power management, but he doesn't have this issue when two conditions are met: 
1. Patched kernel: https://www.spinics.net/lists/linux-acpi/msg69270.html
2. systemd suspend handling disabled.
Comment 29 RussianNeuroMancer 2016-09-28 16:38:23 UTC
I testing kernel with this patches https://www.spinics.net/lists/linux-acpi/msg69270.html and there what I find:

If wake up was initiated by keyboard it always will be successful.
If wake up was initiated by press on powerbutton tablet will wakeup and then immediately suspend again, every time (not twice, but every time).

Now important part:
When tablet is suspended, I can press powerbutton, but instead of releasing finger from powerbutton, I may hold it, then tablet WILL NOT suspend UNTIL I RELEASE FINGER FROM BUTTON. (But holding power button for ten second will power down tablet anyway, as usually.)
By the way, pressing volume buttons on this tablet generate two volume up or volume down actions too, so powerbutton probably works in the same way.

Conclusion:
There still some hiccups with powerbutton handling (that hopefully will get fixed until patches get upstreamed) but this patches actually fixed suspend/wakeup with keyboard, so hopefully not much left.

Is anyone can review Alexander patches?
Comment 30 Zhang Rui 2016-12-22 02:07:17 UTC
Both the button issue and the patch you mentioned above are discussed in bug 102281.
So mark it as duplicate

*** This bug has been marked as a duplicate of bug 102281 ***

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