On Sat, 2016-08-27 at 13:38 +0200, AW wrote:

Am Samstag, 27. August 2016, 13:05:26 CEST schrieb Dominique Leuenberger /  DimStar:

...

=> How do you expect that amount of RAM to be written down to the swap partition for hibernate to work?

Well, it worked for 15 years to have a swap partition half the size of RAM, so  there has been a change...

And I simply do office work on this laptop.

Maybe the 'workload' changed? I am not sure how reliable it is, but I'd assume that if you happen to 'consume' less than 4GB of RAM at the time you try to hibernate, this works - if you consume more, it fails. This might well also point to an application that is leaking memory - or an application simply making use of more memory as long as it's around (caching). I'd recommend to have a quick look at 'free' before you 'hibernate' in order to be able to verify if above statement might have anything to do with it. Possibly also check which application might have increased its memory usage. If it's beyond normal, this one might warrant a bug report. Good luck chasing that one Cheers Dominique

On 2016-08-27 13:05, Dominique Leuenberger / DimStar wrote:

On Sat, 2016-08-27 at 13:01 +0200, AW wrote:

...

Dear all,

I'm a user of TW -- stable enough _and_ interesting.

Since some monthes hibernate (s2disk) is broken, I filed a bug report here:

https://bugzilla.opensuse.org/show_bug.cgi?id=993472

Does anybody else use hibernate and encounters the same crash? Or is it only me? Yesterday the notebook resumed once, but this morning it rebooted "from scratch" again. I don't even know whether it is a kernel or a KDE issue.

I only had a VERY brief read on that bug, but:

RAM 8BG, Swap 4 GB in /dev/sda1.

=> How do you expect that amount of RAM to be written down to the swap partition for hibernate to work?

The system should then tell him that it is impossible to hibernate, never crash. The RAM is compressed in swap, and buffers/cache is not stored. Only really used ram is swapped. I assume that the kernel is clever enough to do some quick checking and then it goes ahead. But maybe it doesn't. Me, I would reserve 12 GiB of swap space. Then, I also disable the splash screen, both on boot and on hibernate. Implies removing plymouth from the system. On systems that use pm-utils I would edit "/etc/suspend.conf": suspend loglevel = 255 splash = n However, tumbleweed does not use pm-utils, so where is this configured now? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-08-27 20:38, Olaf Hering wrote:

Am 27. August 2016 20:14:17 MESZ, schrieb "Carlos E. R." :

...

However, tumbleweed does not use pm-utils, so where is this configured now?

With zypper:

zypper rm -u libply4 zypper al "libply*"

That's plymouth, yes. Remains where to tell hibernation to do it in text mode, no splash. I can not test this, because my TW system runs under vmware, and hibernation there has been broken for years. Instead, I use vmware's own image hibernation. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Sat, 27 Aug 2016 14:10:24 +0200, Olaf Hering wrote:

Am 27. August 2016 13:01:14 MESZ, schrieb AW :

...

Does anybody else use hibernate and encounters the same crash?

A few days/weeks ago I forgot to plugin the power cable, and as a result there was a sudden suspend to disk. I was able to resume from the swap partition. So its likely hardware specific.

If you are curious, install kernel-vanilla and report it also upstream at bugzilla.kernel.org. Maybe its a regression? Install the 4.4 based kernel from Leap 42.2 to check if it works any better.

http://download.opensuse.org/repositories/Kernel:/openSUSE-42.2/standard/Ker...

I've been hunting the S4 problem for a while (mostly for SLE12-SP2), and my finding is: this is no new problem. The first "regression" was introduced in 4.2 kernel. Since then S4 has been broken, occasionally reboots. The reboot probability increased since 4.3. Then, the S4 issue has been improved in 4.7, and again more stabilized in the recent 4.8-rc. With 4.8-rc, I didn't see this problem any longer. Funnily enough, both the regression and the fix above are irrelevant with the real culprits. Yes, it's plural: there are multiple causes leading to S4 resume problems. AFAIK, one is in arch/x86/power stuff, and another is in i915 driver. But the commits that caused the apparent regressions and fixes mentioned above were all about mm changes. They just casually triggered or cured the hidden issues by some mystic reason. In anyway, I'm going to backport the fixes to TW kernel in the next week. Let's see whether it addresses enough. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org