Cannot hibernate or suspend properly ; systemd-sleep hangs

[Yann Salmon]

Hello,
on recent kernels including 4.4.0-57-generic, I observe more often than not the following behaviour after clicking the Hibernate button in XFCE4 interface :

1. Screen becomes black
2. No hard drive activity, which is suspicious
3. Moving the mouse shows the "locked screen" lightdm prompt
4. Unlocking the session, I get back to it ; things seems to work as usual except the ethernet connection is down
5. ps aux | grep hib shows that there is a /lib/systemd/systemd-sleep hibernate running
6. if I kill this process, the computer finally hibernates
7. booting the computer again resumes the session (with networking enabled) but with persistent graphical glitches on some parts of the interface, most visibly
  a. in my terminal, all occurrences of the letter b are scrambled
  b. in all windows, the maximise/minimise/close buttons are scrambled.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: systemd 229-4ubuntu13
ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35
Uname: Linux 4.4.0-57-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.1-0ubuntu2.4
Architecture: amd64
CurrentDesktop: XFCE
Date: Sun Dec 25 10:36:33 2016
InstallationDate: Installed on 2016-09-07 (108 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
MachineType: Dell Inc. Precision Tower 3620
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-57-generic.efi.signed root=UUID=6ebb7e70-29f5-4ddf-a1a1-8cc58113961a ro
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf
 [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/26/2016
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.3.6
dmi.board.name: 09WH54
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 6
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.3.6:bd05/26/2016:svnDellInc.:pnPrecisionTower3620:pvr:rvnDellInc.:rn09WH54:rvrA00:cvnDellInc.:ct6:cvr:
dmi.product.name: Precision Tower 3620
dmi.sys.vendor: Dell Inc.

[Yann Salmon (yannsalmon)]

I disabled legcy BIOS boot as suggested in https://devtalk.nvidia.com/default/topic/827139/linux/uefi-nvidia-vga-console-complaints-/post/4514063/#4514063

So far, it seems to improve things : no problem to this day (but it used to be intermittent, so a few days test is not already conclusive).

[Yann Salmon (yannsalmon)]

The above described problem happens again, now, in spite of what I tried in an earlier comment.

[Dimitri John Ledkov (xnox)]

If resume completed - e.g. there is some evidence that it was not a cold boot, but actually previous system session did come back up somewhat - systemd has probably finished its job.

Graphical glitches are possibly kernel drivers and/or udev/quirk integration.

Assigning to linux for further investigation.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream stable kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.4 stable kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.52

[Yann Salmon (yannsalmon)]

Note : this persists after switching to driver nvidia-375.

[Yann Salmon (yannsalmon)]

Update : this is still happening. This also happens with suspend-to-RAM.

When this happens, it is still possible to order another hibernation : usually this triggers the first hibernation process to proceed. On powering the machine on again, the systems thaws and immediately hibernates again (presumably because of the second order). One can then thaw.

[Yann Salmon (yannsalmon)]

Judging by the absence of the line "Hibernation is possible, Active" in the log when this problem occurs, I think that the execution of systemd-sleep does not reach line 256 in sleep-config.c <https://github.com/systemd/systemd/blob/da4128543ffc5042dc9f6b6f1d22ec72b77b17b3/src/shared/sleep-config.c#L256> which is part of a function named enough_memory_for_hibernation and is indirectly called by line 208 in sleep.c <https://github.com/systemd/systemd/blob/master/src/sleep/sleep.c#L208>.

I will set the SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK environment variable to true as this seems to shortcut this function.

[Yann Salmon (yannsalmon)]

Setting SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK dos not change anything but this seems logical as this was introduced in a recent version of systemd and does not exist in systemd 229.

Creating a /etc/systemd/sleep.conf with SuspendState=mem (to avoid cycling through different suspending modes) does nto improve things either.

When this problem occurs (ie. suspend process started but hanging), I cannot manually write mem to /sys/power/state ; trying to do so fails with a "device is busy" error.