Problems with hibernation on HP ProBook 450 G!
 

Hello,
I have a HP ProBook 450 G1 notebook (Intel i5 Haswell processor, embedded graphics) and I have a problem with hibernation.
The problem is this: after thawing, the system in unstable. A consistent behaviour is that after two hibernations (without rebooting), the second thaw seems to put the system in a working state, but actually it does not: if you try to start applications they won't start and, after some clicks, the system usually freezes completely.
/var/log/pm-suspend.log does not reveal anything interesting.
/var/log/syslog shows "general protection faults" when this happens. This is just an example:

I searched the Internet for things to try.
The page at: http://trisquel.info/en/wiki/trouble...spendhibernate
suggests two things:

1. to disable the wifi card before hibernation with "rfkill block" and restore it after thaw with "rfkill unblock" through a proper script in /usr/lib/pm-utils/sleep.d/, but this didn't help
2. to boot with "nomodeset" kernel parameter, but this causes the video card to not work properly (graphics is completely corrupted, the system is not usable)

Then I looked at:
https://www.kernel.org/doc/Documenta...-debugging.txt
and followed the instructions given there to try to understand what can be the cause of this problem.
All the test modes for hibernation seem to work properly: even if I apply them repeatedly (without a reboot in the middle), the system continues to work properly.
Then I tried to reboot with minimal configuration, using the "init=/bin/bash" kernel boot parameter: well, I don't know if my test is significant, because in this way I can't even mount the root filesystem (which is encrypted), but trying to hibernate in that minimal command prompt seem to work fine.
So I tried to see if I could make hibernation work by unloading kernel modules. This is the list of modules that are normally loaded in my system:
The best I could do by blacklisting modules, obtaining a system that at least can mount my encrypted root filesystem and can lead me to a usable system (by "usable" I mean that I can test if hibernation and thaw work ;-)), was to get to the following minimal list of loaded modules:

But even with so few modules loaded, the problem persists: after a couple of hibernation attempts, the system is unstable and crashes after some seconds of use.

At this point I really don't know what I can further do to try to discover the source of this problem (and, hopefully, a solution).

Suspend-to-RAM seems to work fine: I never had problems with it!

My system is a Linux Mint 17 KDE (based on Ubuntu 14.04) and the kernel version is:
3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I had the same problem with Mint 16 (based on Ubuntu 13.10).
This is a notebook system and I would really need to make hibernation work correctly... :-(

Thanks in advance for any help.

Mauro

Are you running wine, by any chance?

General Protection Fault is windows speak, and linux usually tells you exactly what happened. Kill wine and all such m$ type stuff and see if that sorts the problem. The '0000' address suggests something is addressing low memory, but linux has that protected with most kernels.

If killing wine does sort it, you can reenable the software bit by bit, and see what introduces an error.

Hi business_kid,
thanks for you feedback.
I have wine installed, but there's no wine process running when I hibernate.
I have TeamViewer installed, whose Linux version seems to be based on wine. I ensured that no teamviewer process/service were running either (I had to stop the teamviewerd service), but even then thawing after hibernation failed, this time even after just the first hibernation cycle... :mad:

Well, looking a bit closer at what actually dies
That certainly suggests something else to be killed before you hibernate! It's unusual to see a process spread over 4 cpus like that. The 'tainted' implies something did not match. Network processes can be fussy in hibernation, because it wakes up some unknown time later. Maybe turn your attention to that?

If I understand it well, you are suggesting to kill bluedevl-monol before hibernation, aren't you? I will try that, thank you, although I'm not sure whether bluedevil-monol only appears in the example trace I pasted here or in all ones, I should take a better look to syslogs.

My feeling is that random processes fail randomly after thawing, maybe a hardware state restoration problem? :-(
Does anyone know of any known issue with recent hardware (this is a Haswell system) which might be fixed in more recent kernel releases?

I suspect this is my problem... https://bugzilla.kernel.org/show_bug.cgi?id=59321

Yes, that certainly looks good.

No harm to mention your problems, thereby volunteering as a tester if this bugs you. I went through one of these recently
http://www.linuxquestions.org/questi...em-4175525065/

I ended up doing a git bisect, downloading the linus-stable git of kernel and building some 20 kernels, but it usually isn't that bad. With that, they may even be able to send you a working .config for your kernel.

Just an update: I tested many kernel releases for Linux Mint 17/Ubuntu 14.04, up to version 3.19.0-26, but my system still can't resume properly from hibernation :'-(

Stand-by works well, hibernation does not. This is really limiting for a laptop system...

Go back to the 'tainted' bit. If you have something the kernel sees as 'tainted' get it out.

Instead of installing stock linux mint, I would use the latest haswell drivers cpmpiled from git. Latest Mesa also.Then you get control. Be sure to use packages, so you can revert Do not run 'make install', but make a system package & install that.

I would also try a live cd from the Red Hat stable (e.g. Fedora). They patch stuff there contibually and one version might work for you.

After years of useless tests with newer and newer kernels, I discovered that the only way to make resume from hibernation work on this notebook (HP ProBook 450 G1) is to use the "acpi_osi=Linux" kernel boot parameter.

Just in case someone else faces this problem...