s2disk freezes at saving image to disk (hibernation)

[Matheus]

This started happening after I upgrade to ubuntu 18.04.2. In 18.04.1 hibernation was working flawlessly on my machine. (with kernel 4.15-46! not a kernel issue then?)

Another thing that got updated recently was nvidia drivers which were known to cause hibernation issues, but those were on restoring the snapshot.

http://imgur.com/gallery/jOyHEcL --> I get stuck on this screen after running hibernate or pm-hibernate. (sys-req REISUB combination works there and is the only good way to restart I found)

SPECS

Laptop Dell Inspiron 7567 A30P
Intel Core i7-7700HQ
1x 16 GB DDR4
1 TB HDD + 256 GB SSD
Nvidia GeForce GTX 1050
Ti FHD display
Intel Dual Band Wireless AC 3165
1x1 Motherboard:
Intel HM175 Graphics adapter:
NVIDIA GeForce GTX 1050 Ti (Laptop) - 4096 MB,
Core: 1620 MHz,
Memory: 1752 MHz,
GDDR5, 21.21.13.7320 (ForceWare 373.20),
Nvidia Optimus

nvidia driver: 415.27

INFO

# uname -a
Linux matheus-Inspiron-15-7000-Gaming 4.15.0-46-generic #49-Ubuntu SMP Wed Feb 6 09:33:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

# free -m
              total used free shared buff/cache available
Mem: 15906 2925 8742 161 4238 12485
Swap: 16333 0 16333

# cat /etc/fstab | grep swap
# swap was on /dev/sda8 during installation
UUID=70d967e6-ad52-4c21-baf0-01a813ccc6ac none swap sw 0 0
n

root@matheus-Inspiron-15-7000-Gaming:/home/matheus# cat /var/log/syslog | grep hibernate
root@matheus-Inspiron-15-7000-Gaming:/home/matheus# cat /var/log/syslog | grep hiber
root@matheus-Inspiron-15-7000-Gaming:/home/matheus# cat /var/log/syslog | grep s2disk
root@matheus-Inspiron-15-7000-Gaming:/home/matheus# cat /var/log/syslog | grep hibernation

I could find nothing scrolling up on syslog about the hibernation process or with grep....

An interesting Note is that if I run hibernate just after I boot, it works and resumes perfectly! But after some system usage it randomly has that problem if I try. The percentage it freezes at is also random, sometimes 0, 1 even 30 once.
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/pcmC0D0c: matheus 25949 F...m pulseaudio
 /dev/snd/pcmC0D0p: matheus 25949 F...m pulseaudio
 /dev/snd/controlC0: matheus 25949 F.... pulseaudio
 /dev/snd/seq: matheus 4986 f.... qsynth
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=bfc6f294-b737-4999-a444-01e1f410de06
InstallationDate: Installed on 2018-05-10 (308 days ago)
InstallationMedia: Kubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
MachineType: Dell Inc. Inspiron 15 7000 Gaming
NonfreeKernelModules: nvidia_modeset nvidia
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-46-generic root=UUID=659db14c-2a6c-4f9c-93bf-d31c4a84abb6 ro nouveau.blacklist=1 debug no_console_suspend systemd.log_level=info nvidia-drm.modeset=0
ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-46-generic N/A
 linux-backports-modules-4.15.0-46-generic N/A
 linux-firmware 1.173.3
Tags: bionic
Uname: Linux 4.15.0-46-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm audio cdrom dip kvm lpadmin netdev plugdev sambashare sudo vboxusers
_MarkForUpload: True
dmi.bios.date: 08/15/2018
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.8.1
dmi.board.name: 0P84C9
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.8.1:bd08/15/2018:svnDellInc.:pnInspiron157000Gaming:pvr:rvnDellInc.:rn0P84C9:rvrA01:cvnDellInc.:ct10:cvr:
dmi.product.family: Inspiron
dmi.product.name: Inspiron 15 7000 Gaming
dmi.sys.vendor: Dell Inc.

[Sebastien Bacher (seb128)]

unsure if that's the kernel or not, but that's a better bet that the settings UI you reported the bug against

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1819915

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Matheus (mattfly)]

apport information

[Kai-Heng Feng (kaihengfeng)]

Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v5.0 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'.

Once testing of the upstream kernel is complete, please mark this bug as
"Confirmed”, and attach dmesg.

Thanks in advance.

[0] https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0/

[Matheus (mattfly)]

Same result (freeze on s2disk screen) in both kernels.

[Kai-Heng Feng (kaihengfeng)]

So does this happen to 4.15 + Nvidia driver?

[Matheus (mattfly)]

Yes this is exactly how this this is happening. kernel 4.15 + propretary nvidia drivers, either with those drivers enabled or uninstalled. Also tested on kernel 5 without nvidia drivers.

[Matheus (mattfly)]

Another thing I noticed is that changing from one DE to another does change nothing, Gnome or KDE same issue.

A weird non tech way to describe it, which is what I can tell, Is that it seems like when my system haven't used more than 2gb of memory yet, I am able to hibernate and restore how many times I want. Otherwise If I try to hibernate when more than 2 gb are used this problem happens.

Also if I open a heavy program like chrome, using more than 2gb and close it quickly, with the system going back to less than 2gb usage, I have the same problem back again. So it really seems like after I used something that is about 2gb this error happens, even if I close everything, exit xorg and go back to a 500 mb ram usage and try hibernating from the tty.

I tried recreating my swap partition, which has 16gb of space, so nothing against 2 gb?!?... but nothing fixes this. By the way I have less than 16 gb of space left on my home partition and / partition but I really don't think this would affect anything since I'm not using those.

Honestly can't find any more logical explaining for this or way to troubleshoot now.

[Kai-Heng Feng (kaihengfeng)]

Sorry this is a bit confusing. The bug description says it works with v4.15 but now it doesn't?
What changes made the hibernation stops working?

[Matheus (mattfly)]

As I said, the major change that I remember was updating from ubuntu 18.04.1 to 18.04.2. I'm attaching my apt history log to this message. I am 100% sure that hibernation wasn't crashing and worked flawlessly on 02/06/2019 and it wasn't anymore in 03/04/2019.

The bug I'm trying to describe happens in either 4.15 or kernel 5.0, the thing is that if it wasn't ever used more than, something around 2gb, of ram memory, the "s2disk saving image to disk" freeze doesn't happen and I'm able to resume normally. That's on both kernels too. What I want to make clear is that this isn't some sort of broken swap partition with storage limitations, because even if i close all programs after such 2gb usage the problem still happens.

Maybe I should make a huge downgrade and check out what package causes it? I'm not sure though how to do that via apt.

[Kai-Heng Feng (kaihengfeng)]

Yes please. Most likely it's cause by kernel and drivers update.

[Matheus (mattfly)]

What packages you recommend me downgrade there?

[Kai-Heng Feng (kaihengfeng)]

Linux kernel and DKMS.

[Matheus (mattfly)]

Alright, today finally had some time and installed older kernels. 4.15.0-42 , 4.15.0-44, 4.15.0-45 and on the last I had the same bug as always. I installed the older linux images, with apt, and runed initramfs:

# update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
I: The initramfs will attempt to resume from /dev/sda8
I: (UUID=70d967e6-ad52-4c21-baf0-01a813ccc6ac)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic
I: The initramfs will attempt to resume from /dev/sda8
I: (UUID=70d967e6-ad52-4c21-baf0-01a813ccc6ac)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-4.15.0-44-generic
I: The initramfs will attempt to resume from /dev/sda8
I: (UUID=70d967e6-ad52-4c21-baf0-01a813ccc6ac)
I: Set the RESUME variable to override this.
update-initramfs: Generating /boot/initrd.img-4.15.0-42-generic
I: The initramfs will attempt to resume from /dev/sda8
I: (UUID=70d967e6-ad52-4c21-baf0-01a813ccc6ac)
I: Set the RESUME variable to override this.

70d967e6-ad52-4c21-baf0-01a813ccc6ac is my real swap!

problem is, with the other two kernels I'm not able to boot up. I get stuck on this screen: http://imgur.com/gallery/kLPMFhg

I'm sure that on those kernels I didn't have the issue!

Waited, hit ctrl+c, the tty worked (switchign with ctrl+alt+F2). But there was no connection, ifconfig didn't show either my eth0 or wlan0.... well that was very buggy... and i was thinking on reinstalling the nvidia kernels from there since it could be just a graphical glitch. No clue how to test older kernels on ubuntu.

Also noticed that this 2gb thing I said is not totally right. Seems like it's more likely it will happen if 2gb was used, but I still had the problem randomly just after a boot and not even logged into a DE, just from tty...

[Matheus (mattfly)]

Ok so after running the right command to install the older kernel:

apt-get install linux-image-4.15.0-44-generic linux-headers-4.15.0-44 linux-headers-4.15.0-44-generic linux-modules-extra-4.15.0-44

Also tested with -42 and -43 versions, Hibernation worked just like before with 4.15.0-43. So We can state this is a kernel bug since kernel 4.15.0-44, since with the -46, -45, -44 versions it doesn't work. It also worked on the -42 version.

[Matheus (mattfly)]

Okay, forget what I said, I just randomly run into the freeze with the the -43 version after 3 hibernation cycles, Ill be testing with -42 now....

[Matheus (mattfly)]

also just happened on the -42 version now... Seems like was less likely to happen in older versions. I remember 2 months ago I made more than 10 hibernation cycles. Not sure whats happening now...

[Kai-Heng Feng (kaihengfeng)]

So maybe it's caused by Nvidia driver update?

[Matheus (mattfly)]

I don't think that's the issue. The nvidia problem I was used to is being unable to resume. I also tested with the nvidia drivers disabled and this issue still persists. Something I noticed is that I was not on the recommended version of nvidia drivers which is 415 and I just changed that now upgrading to 418. Still exactly the same issue.

Tested with various DE's and even out DE's running. Do you have any other guess? Is there a better way to find out what's wrong? To see dmesg while it is trying to hibernate maybe?

[Kai-Heng Feng (kaihengfeng)]

Maybe try older kernel releases from Artful (4.13) or Zesty (4.10).

[Matheus (mattfly)]

With the recomended nvidia driver and low ram usage, the system sucessfully hibernates, but then fails to resume and I get the login screen instead. With high ram usage it hangs trying to save the image to disk. That's a new behaviour to me.

[Matheus (mattfly)]

No, I am 100% sure it worked with kernel 4.15.0-42 and with the nvidia proprietary driver nvidia-415 before the version .27

Also always worked fine without any nvidia driver, specially for the upstream kernel. I test this since more than one year...

[Matheus (mattfly)]

Isn't there a way to extract logs from s2disk or uswsusp???

[Matheus (mattfly)]

So... After reconfiguring uswsusp I increased logging level to 7. Also i tried disabling the nvidia modules again but the same issue persists. This is the information I could get:

http://imgur.com/gallery/YirJhdx

The upper image shows what happens while trying to hibernate with nvidia modules enabled and on the other they were disabled. In both cases, hibernation works fine at first, even with 4 gb of ram usage and 2 hibernation cycles, but after I use the system more, and looks like the more ram gets used more likely it is the issue to happen. If I keep not opening programs or using the OS at all except for hibernating again and again after it turns on, seems like hibernation will work indefinitely.

I thought it could be some specific program but I confirmed it's not, at least not something I am directly starting.

[Matheus (mattfly)]

After researching a bit and with the help of a friend, I thought it could be the i915 module due to the drm and rc6, which in fact was in use:

# lsmod | grep i915
i915 1617920 3
i2c_algo_bit 16384 1 i915
drm_kms_helper 172032 2 nvidia_drm,i915
drm 401408 16 drm_kms_helper,nvidia_drm,i915
video 45056 3 dell_wmi,dell_laptop,i915

I added:

install i915 /bin/false

to the file /etc/modprobe.d/blacklist.conf

Restarted and booted back up, I couldn't see nothing anymore but input my password and login worked, since I have synergy and it activated input on another screen.... But was a black screen.

Still this didn't fix anything. Just hibernated at first and worked fine! Problem found I thought... Then I used strees command to alocate 14 gb of memory and hibernate, it worked!! that never happened before with that much ram allocated, but then after it resumed I just tried again and failed, kinda randomly like always... Stuck on this screen:
http://imgur.com/gallery/xgT7VWh

So even with i915 module disabled the issue is still the same...

[Kai-Heng Feng (kaihengfeng)]

I can successfully hibernate/resume Inspiron 7567 with kernel 4.18.0-17-generic, when Intel graphics is selected.

[Matheus (mattfly)]

Could you please test or tell what happens with nvidia selected? It used to worked fine to me with nvidia too, as I said before. Are you on the latest release? 18.04.2? Up to date? I haven't tested that kernel yet, and it wasn't automatically installed running apt upgrade or full-upgrade.... I'm running:

apt install linux-image-4.18.0-17-generic linux-modules-4.18.0-17-generic
 linux-headers-4.18.0-17-generic linux-modules-extra-4.18.0-17-generic

To install it.

Well I just tested with intel or nvidia and just as always:

https://imgur.com/a/FKJq9we

I suspect the issue has to do with another application or module.... Will possibly work if i do a fresh install... but that's such a lazy solution and I won't really find the bug then. Anyway I might test a fresh install anytime.

[Kai-Heng Feng (kaihengfeng)]

> Could you please test or tell what happens with nvidia selected?
Hang at freeze or thaw stage. Can't really tell.
Nothing much as I do as it's proprietary.

> Are you on the latest release? 18.04.2? Up to date?
Both kernel 4.15 and 4.18.

I did increase the size of swapfile to match the RAM size though.

[Matheus (mattfly)]

Are really you using uswsusp? (hibernate command), pm-utils (pm-hibernate) or systemctl hibernate?

[Kai-Heng Feng (kaihengfeng)]

systemctl hibernate

[Matheus (mattfly)]

Okay I found a way to get it working, first I gave up of uswsusp and runned:

apt remove --purge hibernate uswsusp.

I basically followed this: https://askubuntu.com/a/1064114
but changed to:
resume=/dev/disk/by-uuid/70d967e6-ad52-4c21-baf0-01a813ccc6ac (just
the uuid wouldn't work so the path /dev/disk/by-uuid/ did the trick!) and this is probably the most important thing to do. It worked!
I think the most important is setting resume=UUID=<#> in both /etc/default/grub and /etc/initramfs-tools/conf.d/resume. Maybe this could be automatically configured?

I tested both systemctl hibernate and pm-hibernate, I guess they call
the same thing anyway. Working flawlessly even with nvidia prime selected! (until now...)

[Matheus (mattfly)]

This seems to be an old bug with uswsusp, which is an old package: https://bugzilla.kernel.org/show_bug.cgi?id=75101

I think I first started using it because it was easier to set up and I heard it was better for nvidia proprietary modules.

[Johnathan (gen000)]

I've also been experiencing a similar issue for some time - occurring intermittently, not when I'm using only a small amount of RAM - where s2disk would hang on writing the image:
s2disk: Saving xxxx image data pages (press backspace to abort) ... 0%

On Ubuntu 18.04 (currently 4.18 kernel)

In case it is of use to anyone else who finds this bug, I was able to work around this by writing a Hibernate script and assigning a keyboard shortcut to it:

#!/bin/sh
echo Unlimiting IO cache...
sudo sysctl -w vm.dirty_ratio=100
sudo sysctl -w vm.dirty_background_ratio=100

sleep 5
sudo s2disk

echo Re-limiting IO cache...
sudo sysctl -w vm.dirty_background_ratio=10
sudo sysctl -w vm.dirty_ratio=20

This disables cached disk IO for the hibernate and restores it after resume. It seems to work reliably for the past few weeks for me anyway.