No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3

[dmoe...@gmail.com]

Hi,

I have a Dell Latitude 7400 (Core i5-8365U "Whiskey Lake"). I installed Qubes 4.0.2rc3, and everything seems to mostly work except it won't resume from suspend. The screen stays totally black, and I have to hold the power button to manually restart it.

I've tried the following:

1. Shutdown sys-net before suspending.

2. Shutdown sys-usb before suspending.

3. Disable TPM in the BIOS (Inspired by https://github.com/QubesOS/qubes-issues/issues/3705)

4. Disable Thunderbolt in the BIOS

5. Use kernel-latest

None of this works. It's quite similar to what's described here, but this machine is not corebooted: https://groups.google.com/forum/#!topic/qubes-users/bHJJhK4HtIw

There it's suggested that I should remove a check in xen and recompile, but I'll try that as a last resort. Any other ideas?

Doubt it's connected, but two other things I noticed: First, Qubes won't actually shutdown the computer, even after shutting down I always have to use the power button. But I've had this problem with other laptops. Second, there's no bootsplash for the encrypted HD.

Best,

Daniel

[dmoe...@gmail.com]

The suspending problem was s2idle. Adding mem_sleep_default=deep to the kernel= line of /boot/efi/EFI/qubes/xen.cfg fixes the suspend problem.

Installing kernel-latest (5.3.11-1) fixes the last two problems with completing shutdown and with a lack of a bootsplash.

I'll post an HCL in a moment. Everything now works flawlessly.

Daniel

[Guerlan]

can you tell me how you figured this out? I've been trying to fix a suspend bug in mine and It'd be helpful to know how you debugged things

[dmoe...@gmail.com]

On Sunday, January 5, 2020 at 9:49:42 PM UTC-5, Guerlan wrote:

can you tell me how you figured this out? I've been trying to fix a suspend bug in mine and It'd be helpful to know how you debugged things

Mostly trial and error, trying all the things listed above. Two little tricks to use:

1. Look at the end of journalctl right before it tries to suspend. This is where I saw that it was going into s2idle, which then brought me to this thread: https://groups.google.com/forum/#!msg/qubes-users/TmGDlkluJgM/1BFsQZWNDAAJ;context-place=forum/qubes-users This Dell did not have the lack of S3 that the new Thinkpads have, but it did still try to use s2idle.

2. Run speaker-test in dom0 before suspending, if you hear sound on resume then it's some sort of a screen problem.

What hardware do you have? If it's corebooted you might want to check out this thread: https://groups.google.com/forum/#!msg/qubes-users/bHJJhK4HtIw/ieQkoJePCgAJ

[Claudia]

January 6, 2020 3:14 AM, dmoe...@gmail.com wrote:

> On Sunday, January 5, 2020 at 9:49:42 PM UTC-5, Guerlan wrote:
>> can you tell me how you figured this out? I've been trying to fix a suspend bug in mine and It'd be
>> helpful to know how you debugged things
>
> Mostly trial and error, trying all the things listed above. Two little tricks to use:
>
> 1. Look at the end of journalctl right before it tries to suspend. This is where I saw that it was
> going into s2idle, which then brought me to this thread:
> https://groups.google.com/forum/#!msg/qubes-users/TmGDlkluJgM/1BFsQZWNDAAJ;context-place=forum/qubes

> users This Dell did not have the lack of S3 that the new Thinkpads have, but it did still try to
> use s2idle.

/sys/power/mem_sleep will list supported modes, with the default in brackets. You can echo to it to set the default at runtime, or use the boot parameter.

[Guerlan]

 [lz@dom0 ~]$ cat /sys/power/mem_sleep
s2idle [deep]

What does this mean? It means that it detected only s2idle or that my system does not support suspend to RAM? I've used Ubuntu and Fedora and lid closing always worked, I just don't know if it was idle or to ram or other thing.

[Claudia]

This means that s2idle mode and deep mode are the two modes supported by your machine, and that deep is the mode that will be used for sleep when no specific mode is specified, such as using the lid switch or the logout menu or systemctl suspend for example. In OP's case, deep is manually set as default using the kernel parameter mem_sleep_default=deep. Generally the kernel chooses the deepest mode supported (s2idle -> shallow -> deep) to be the default, but on some machines the kernel will choose s2idle as the default even if deep is supported.

https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation

[Guerlan]

Thanks! I now understand how it works. I've checked and indeed my system defaults to deep. I tried s2idle by doing echo freeze > /sys/power/state and the screen turns off but they keyboard keeps with lights on. Pressing buttons does nothing. Pressing touchpad, nothing. Pressing power rapidly, nothing. Had to reboot by long pressing power. Shouldn't s2idle always work since it's software based?

I also followed the dmoe...@gmail.com tip of viewing journalctl just before suspend:

Jan 07 20:56:24 dom0 systemd-logind[1925]: Lid closed.
Jan 07 20:56:24 dom0 systemd-logind[1925]: Suspending...
Jan 07 20:56:24 dom0 systemd[1]: Starting Qubes suspend hooks...
Jan 07 20:56:25 dom0 qmemman.daemon.algo[1921]: balance_when_enough_memory(xen_free_memory=8172072647, total_mem_pref=2493652659.2, total_available_memory=13171544083.8)
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '5' act=3198156800 pref=963591782.4 last_target=3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '0' act=4294967296 pref=1530060876.8 last_target=4294967296
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447 memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 5 to 3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 0 to 4294967296
Jan 07 20:56:25 dom0 qrexec[3884]: qubes.GetDate: social -> @default: allowed to dom0
Jan 07 20:56:25 dom0 qmemman.daemon.algo[1921]: balance_when_enough_memory(xen_free_memory=8172072647, total_mem_pref=2450575027.2, total_available_memory=13214621715.8)
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '5' act=3198156800 pref=920514150.4 last_target=3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '0' act=4294967296 pref=1530060876.8 last_target=4294967296
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447 memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 5 to 3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 0 to 4294967296
Jan 07 20:56:26 dom0 qmemman.daemon.algo[1921]: balance_when_enough_memory(xen_free_memory=8172072647, total_mem_pref=2398557056.0, total_available_memory=13266639687.0)
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: dom '5' act=3198156800 pref=920514150.4 last_target=3198156800
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: dom '0' act=4294967296 pref=1478042905.6000001 last_target=4294967296
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447 memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: mem-set domain 5 to 3198156800
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: mem-set domain 0 to 4294967296
Jan 07 20:56:26 dom0 qmemman.daemon.algo[1921]: balance_when_enough_memory(xen_free_memory=8172072647, total_mem_pref=2398557056.0, total_available_memory=13266639687.0)
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: dom '5' act=3198156800 pref=920514150.4 last_target=3198156800
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: dom '0' act=4294967296 pref=1478042905.6000001 last_target=4294967296
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447 memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: mem-set domain 5 to 3198156800
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: mem-set domain 0 to 4294967296
Jan 07 20:56:27 dom0 qmemman.daemon.algo[1921]: balance_when_enough_memory(xen_free_memory=8172072647, total_mem_pref=2398557056.0, total_available_memory=13266639687.0)
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: stat: dom '5' act=3198156800 pref=920514150.4 last_target=3198156800
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: stat: dom '0' act=4294967296 pref=1478042905.6000001 last_target=4294967296
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447 memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: mem-set domain 5 to 3198156800
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: mem-set domain 0 to 4294967296
Jan 07 20:56:27 dom0 52qubes-pause-vms[3877]: 0
Jan 07 20:56:27 dom0 systemd[1]: Started Qubes suspend hooks.
Jan 07 20:56:27 dom0 systemd[1]: Reached target Sleep.
Jan 07 20:56:27 dom0 systemd[1]: Starting Suspend...
Jan 07 20:56:27 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 07 20:56:27 dom0 kernel: audit: type=1130 audit(1578441387.401:154): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jan 07 20:56:27 dom0 qmemman.daemon.algo[1921]: balance_when_enough_memory(xen_free_memory=8172072647, total_mem_pref=2355229158.4, total_available_memory=13309967584.6)
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: stat: dom '5' act=3198156800 pref=920514150.4 last_target=3198156800
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: stat: dom '0' act=4294967296 pref=1434715008.0 last_target=4294967296
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447 memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: mem-set domain 5 to 3198156800
Jan 07 20:56:27 dom0 qmemman.systemstate[1921]: mem-set domain 0 to 4294967296
Jan 07 20:56:27 dom0 systemd-sleep[3912]: /usr/lib/systemd/system-sleep/custom-xhci_hcd: Going to suspend...
Jan 07 20:56:27 dom0 systemd-sleep[3912]: Suspending system...
Jan 07 20:56:27 dom0 kernel: PM: suspend entry (deep)

this just confirms that it's doing deep suspend, but shows nothing more, I guess.

I have no other ideas. If someone know a little more on how to debug, I'd be glad. Remember that I found this error in ACPI https://github.com/QubesOS/qubes-issues/issues/5555 on dmesg. It indicates that ASPM does not work. Maybe this is crucial?

[Claudia]

>> tem-suspend-and-hibernation
>
> Thanks! I now understand how it works. I've checked and indeed my system defaults to deep. I tried
> s2idle by doing echo freeze > /sys/power/state and the screen turns off but they keyboard keeps
> with lights on. Pressing buttons does nothing. Pressing touchpad, nothing. Pressing power rapidly,
> nothing. Had to reboot by long pressing power. Shouldn't s2idle always work since it's software
> based?

I don't know much about s2idle, but yes, in theory it should be the most reliable of the sleep states. It could be a graphics driver issue. However, from your log it looks like it's still entering deep sleep.

> I have no other ideas. If someone know a little more on how to debug, I'd be glad. Remember that I
> found this error in ACPI https://github.com/QubesOS/qubes-issues/issues/5555 on dmesg. It indicates
> that ASPM does not work. Maybe this is crucial?

Debugging suspend is a long and complicated process. I don't want to get any more off-topic in this thread. Please start a new thread for your machine detailing everything you've tried so far, including logs and any other relevant information, so it's all in one place.

[Guerlan]

Ok thanks, here's the new thread https://groups.google.com/forum/#!topic/qubes-users/eMWxHSy9h7c