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).
Created attachment 228611 [details] dmesg
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.
please attach the content of /proc/acpi/wakeup
Created attachment 228681 [details] wakeup devices /proc/acpi/wakeup output is attached.
(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
Please also upload acpidump output here.
> 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.
Created attachment 229771 [details] acpidump > Please also upload acpidump output here. Attached.
(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
Please test with init=/bin/bash appended in the grub, is the issue still reproduced?
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;
Since we needn't to figure out which is the triggering source of the 2 resume-from-idle, let me reset the bug assignee.
> 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).
Created attachment 229791 [details] dmesg with patched kernel dmesh of suspend/resume cycle with patched kernel.
New dmesg from kernel with patch from Comment 11.
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
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
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.
> 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.
(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
> 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.
(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
Ping Bastien: Please help us to figure out the trigger of the 2nd suspend. Thanks in advance! Lv
> 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).
(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
Created attachment 239751 [details] wakeup content from /bash/init
Created attachment 239761 [details] wakeup content from normal boot
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.
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?
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 ***