Re: Ridiculous hibernation problem

Posted: Fri Dec 01, 2017 7:37 pm

by Mute Ant

You should look at the text in /boot/grub/grub.cfg too. There should be something like...linux blah-blah-blah resume=UUID=a3d68e82-84c5-4a6f-b9f2-edb776b4c3c2 blah-blah-sparklers-blah
...for the kernel to know exactly which partition to fetch into RAM next boot, and I guess the same UUID is used to save-and-hibernate.

Re: Ridiculous hibernation problem

Posted: Sat Dec 02, 2017 8:16 pm

by emil_pavlov

No, both did not work.

Re: Ridiculous hibernation problem

Posted: Sun Dec 03, 2017 6:24 am

by rene

I am assuming that when you say "my computer won't hibernate" you do not just mean that the system won't resume from hibernation but that it will not even start to hibernate; this would make this be a strange problem.

As to the /etc/default/grub advise you got above: resume is handled by the initrd, and you needn't/shouldn't set the resume= parameter manually, nor should any such parameter have an effect on hibernation start; you should remove it from /etc/default/grub again. Remember to rerun sudo update-grub after changing /etc/default/grub.

The resume UUID is on Debian based systems stored in /etc/initramfs-tools/conf.d/resume; simply updating the initrd does not work to update it once set; as far as I can currently find not any automated tool updates it. Which makes some theoretical sense; the system supposedly does not know which one of your potential multitude of swap partitions you use for hibernation. You'll need to plug in the new UUID for your swap partition also in that file and regenerate your initrd's through sudo update-initramfs -u -k all.

Certainly do that now that you remade your swap space with mkswap above but this again concerns resume only. If indeed hibernation in your case won't even start I do not believe to have much interesting to add.

Re: Ridiculous hibernation problem

Posted: Sun Dec 03, 2017 8:35 am

by emil_pavlov

Sorry, I should have explained it better.
My system has no problems with resuming from hibernation. The problem is with going into hibernation. If the used ram is more than 4 Gigs or so, the process will start, the screen will go blank, but after a few seconds system comes back again to normal desktop and reconnects with the wifi. If my used memory drops below that, there is no problem with hibernation. I can actually see error messages from previous failed hibernation attempts since the last restart, which say something like "blabla longer than available space in blabla". It's not partitions or UUID, but some other gibberish. I suspect that some of the hibernation scripts checks for available swap space, but has the old value instead of the current one somehow. Anyway, I will try to write down the error, but it comes on only for a short time.

Indeed, the resume UUID was stored in /etc/initramfs-tools/conf.d/resume, I updated it. I also reverted /etc/default/grub to its default.

Re: Ridiculous hibernation problem

Posted: Sun Dec 03, 2017 9:30 am

by rene

This is from the looks of your kernel version string [edit: or from your original post, of course, ... ] Mint 18.x? You are, or Mint 18.x is, still using the 'pm-utils' but as far as I'm aware those are in fact obsolete these days. Do things work for you if you initiate hibernation from the command line with systemctl hibernate?

Even if they do: I expect you'd probably have commented on things if you had manually installed and set up the 'pm-utils'; that this setup is generic Mint 18.x and that I will as such need to bow out, being still on 17.3 myself. You'd need someone running 18.x to confirm/deny 'pm-utils' still being a standard part of the OS in the first place, and to try/test things in the second. Certainly that I/O error you get at the point of actual hibernate doesn't look good; as far as I'm able to google up it's the actual echoing (of "disk") into /sys/power/state that fails... but investigating why requires someone with an actual 18.x install to look at.

Re: Ridiculous hibernation problem

Posted: Sun Dec 03, 2017 10:07 am

by emil_pavlov

I think it does not use pm-utils by default. I am just too old and did not know any other way to find the error log, so I issued pm-hibernate manually.

[some numbers] mei_me 0000:00:16.0: less data available than length=00000002.

whereas the last digit varies between 2, 3 and 5

Re: Ridiculous hibernation problem

Posted: Sun Dec 03, 2017 10:53 am

by rene

emil_pavlov wrote:systemctl hibernate does not work either, same reason.

You should probably take that to mean that we're looking at something fundamental here; not at any "caching" of your previous 4G swap space. I'd try updating my kernel to the newest series and version thereof available.

The "mei_me" message points at the Intel Management Environment and that is given the 4G to 8G step actually sort of interesting. The Intel ME is basically an in your chipset embedded operating system (Tanenbaum's MINIX for halfway modern versions) which is undoubtedly 32-bit; has a 4G address space. If you are the type of Russian (?) with stuff to hide I'd think about unplugging that system from the net lest MINIX were faulting trying to ship a bit of memory from above 4G to the American NSA, say...

Just kidding.

One thing you can test additionally is echo disk | sudo tee /proc/sys/state as a "most manual" form of hibernation but I don't expect there's going to be a difference wrt. systemctl hibernate. If indeed there isn't I believe we're definitively down to this being a kernel issue, and given the error message, perhaps more specifically the Intel ME driver. I.e., try a different kernel. Or, by the way, try and see if you can set anything regarding ME/AMT in your BIOS. Or through the Windows driver. Or...

[EDIT] Crap, sorry; echo disk | sudo tee /sys/power/state I mean.

Re: Ridiculous hibernation problem

Posted: Sun Dec 03, 2017 4:34 pm

by emil_pavlov

I figured out that the MEI error comes from the intel microcode drivers. So I just disabled them, and this fixed it. The error I mean, not the hibernation.

Re: Ridiculous hibernation problem

Posted: Sun Dec 03, 2017 5:09 pm

by rene

No spy novel fun to be had; figures. Yes, the microcode link seems to make sense; will try to remember that.

Yet another attempt: what happens if you enter echo $((1 * 1024**3)) | sudo tee /sys/power/image_size before attempting to hibernate (in the echo disk | sudo tee /sys/power/state manner or "normally")? I can't myself reproduce an issue with any setting of the image_size parameter but did find an old kernel bug regarding this. If it does in fact help: are you perhaps using for example RAID of encryption for your swap partition? For any partition?

Thing is: your free output confirms 8G RAM and 8G swap, you have updated /etc/initramfs-tools/conf.d/resume with the correct swap UUID, and even if you didn't already do so manually, the installation of the new kernel has certainly both (re)generated the initrd and run update-grub... which is to say that there really seems very little opportunity left for trouble, even potentially. Being unable to reproduce also doesn't help. Rather expect I'll be out of ideas after this ;(

Re: Ridiculous hibernation problem

Posted: Mon Dec 04, 2017 8:31 am

by emil_pavlov

Sorry, no spies.

echo $((1 * 1024**3)) | sudo tee /sys/power/image_size did not help.

uswsusp works regardless of the ram load, but it's not a practical solution for me, because it's much slower

tuxonice works also. however, I cannot install a kernel newer than 4.4, although they have patches for 4.13, which discourages me from using it. If you could help me install the latest kernel patch, this might be solution for me.

I expanded my swap to 16 gig, to see if this would help, but to no avail. I noticed however that the system hibernates (with <4gig ram) and resumes without problems, even though I did not update fstab or initramfs. The swap was recognized out of the box as 16 gig. I guessing the kernel uses a very special way for calculating free swap space.

Anyway, if I don't manage to install the latest tuxonice patched kernel, I will just do a fresh install.

Re: Ridiculous hibernation problem

Posted: Mon Dec 04, 2017 8:52 am

by rene

emil_pavlov wrote:tuxonice works also. however, I cannot install a kernel newer than 4.4, although they have patches for 4.13, which discourages me from using it. If you could help me install the latest kernel patch, this might be solution for me.

I expanded my swap to 16 gig, to see if this would help, but to no avail. I noticed however that the system hibernates (with <4gig ram) and resumes without problems, even though I did not update fstab or initramfs. The swap was recognized out of the box as 16 gig. I guessing the kernel uses a very special way for calculating free swap space.

I'm really quite fully out of ideas as to the nature of your problem...

The following additional packages will be installed:
linux-headers-4.4.0-101-generic-tuxonice linux-headers-generic-tuxonice
linux-image-4.4.0-101-generic-tuxonice
linux-image-extra-4.4.0-101-generic-tuxonice linux-image-generic-tuxonice

I'm really quite fully out of ideas as to the nature of your problem...

Thank you trying nevertheless

Re: Ridiculous hibernation problem

Posted: Mon Dec 04, 2017 9:58 am

by rene

Oh, right, that PPA indeed only publishes a 4.4 kernel for "xenial", i.e., Ubuntu 16.04, the base of Mint 18.x. You could elect to use it if you don't need a newer kernel for anything else but personally I wouldn't either.

Compiling a kernel with tuxonice manually is also not something I'd suggest, and especially not since I don't in fact think it would've been a great idea to install a custom kernel in the first place. Given the PPA it would've at least been a quick fix but reinstalling Mint is likely to be quite a bit quicker if you don't have a lot of stuff to backup first. I have no idea what's happening there; can't reproduce any sort of issue, so, bit lame, but yes, if a reinstall isn't too much trouble, that's what I would advise.