Re: Hibernate in stretch

[solitone]

On Saturday, 29 July 2017 18:40:58 CEST solitone wrote:
> From what I gather, the patch was included in kernel version 4.8-rc2:
> 
> $ git describe bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
> v4.8-rc2-641-gbafb2f7d4755
> 
> The kernel shipped with Stretch is version 4.9.30:
> 
> $ uname -v
> #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)
> 
> but we still experience the bug. This is because, if I understand it right,
> the commit containing this patch was reverted in the production kernel:
> 
> commit 0ee72d8f9b8e17b8e4ccfebc7a25cbc2d395cd6a
> Author: Greg Kroah-Hartman 
> Date:   Wed Apr 12 15:49:39 2017 +0200
> 
> Revert "drm/i915/execlists: Reset RING registers upon resume"
> 
> This reverts commit f2a0409a08502d64fbe3990354dff5902b08d2fb which is
> commit bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae upstream.
> 
> It was reported to have problems.
> 
> I therefore wonder whether this means this bug is still there in the
> production kernel, even in versions greater than 4.9.x.

Yes, that patch ended up in v4.9.9 [1]. Then some problems were reported, and 
it was reverted in v4.9.23 with commit 
0ee72d8f9b8e17b8e4ccfebc7a25cbc2d395cd6a [2].

I have just installed kernel version 4.11.6, from stretch-backports:

~$ uname -a
Linux alan 4.11.0-0.bpo.1-amd64 #1 SMP Debian 4.11.6-1~bpo9+1 (2017-07-09) 
x86_64 GNU/Linux

With that kernel hibernate seems to work, but I need further testing. I would 
suggest you to test that kernel version as well, and post your findings here.

[1] https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.9
[2] https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.23



-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[solitone]

On Wednesday, 26 July 2017 21:48:30 CEST solitone wrote:
> I haven't yet figured out which kernel version contains such patch, though.
> BTW, I have also submitted a bug to debian, pointing out that solution, but
> it doesn't seem to have been considered yet:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869424

From what I gather, the patch was included in kernel version 4.8-rc2:

$ git describe bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
v4.8-rc2-641-gbafb2f7d4755

The kernel shipped with Stretch is version 4.9.30:

$ uname -v
#1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)

but we still experience the bug. This is because, if I understand it right, 
the commit containing this patch was reverted in the production kernel:

commit 0ee72d8f9b8e17b8e4ccfebc7a25cbc2d395cd6a
Author: Greg Kroah-Hartman 
Date:   Wed Apr 12 15:49:39 2017 +0200

Revert "drm/i915/execlists: Reset RING registers upon resume"

This reverts commit f2a0409a08502d64fbe3990354dff5902b08d2fb which is
commit bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae upstream.

It was reported to have problems. [1]

I therefore wonder whether this means this bug is still there in the 
production kernel, even in versions greater than 4.9.x.

[1] https://lists.freedesktop.org/archives/intel-gfx/2017-April/125833.html
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[solitone]

On Thursday, 27 July 2017 00:05:08 CEST Cindy-Sue Causey wrote:
> What I'm remembering is that I would
> close the lid outside, unplug it, bring it inside, plug it back in,
> and open the lid hoping it would wake up as we expect = right where I
> left off out on the porch.
> 
> Quite a few times it did NOT wake up normally. It woke up in the way
> I'm grasping is being described above. It would suddenly, *partially*
> reboot without intervention from me.
> 
> After it went through what appeared to be a normal complete boot, I'd
> then *unexpectedly* end up back at the various *still open* windows
> I'd been using on the porch a few minutes before..

This seems normal when the system recovers from disc. Most likely you had set 
that the system should hibernate when the lid is closed.

> It was VERY nice that at least it did that. It was a curiosity,
> though, that it appeared to go through a "real reboot" where
> expectations are that memory is wiped and everything is gone, zapped.
> But instead of the memory (cache? sorry..) being wiped clean,
> everything I had been working on pulled up exactly as I had left it
> open only minutes before..

This happens because before suspend all the content in RAM is saved 
persistently to disc, specifically to the swap partition. When you tell it to 
recover (e.g. when you open the lid), the system reboots and reads that saved 
image from the swap partition, restoring your previous session.

> Oh, and I would, yes, get the login screen just before it would open
> on up into the previous session that theoretically maybe should not
> have been there.

Again, I think this is also normal. It wouldn't be safe if the user weren't 
asked the password, would it?
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[Cindy-Sue Causey]

On 7/22/17, solitone  wrote:
> On my previous laptop with jessie hibernation didn't work. On my current
> laptop with stretch hibernation doesn't work either.
>
> During the several updates that interested stretch in the last few months,
> the
> symptoms changed, and I don't remember exactly their evolution at the
> moment.
> Currently, when the system resumes, after a few boot messages, everthing
> stalls on a black screen. I don't even get the login screen.


You're partially describing what *I think* I wrote on a different
thread a while back. I had written about strange issues related to the
few minutes in between unplugging the (ASUS 1015px) laptop out on the
front porch and then plugging it back in here inside the house.

My memory's getting foggy on the exact details because it has been so
long since it last happened. What I'm remembering is that I would
close the lid outside, unplug it, bring it inside, plug it back in,
and open the lid hoping it would wake up as we expect = right where I
left off out on the porch.

Quite a few times it did NOT wake up normally. It woke up in the way
I'm grasping is being described above. It would suddenly, *partially*
reboot without intervention from me.

After it went through what appeared to be a normal complete boot, I'd
then *unexpectedly* end up back at the various *still open* windows
I'd been using on the porch a few minutes before..

It was VERY nice that at least it did that. It was a curiosity,
though, that it appeared to go through a "real reboot" where
expectations are that memory is wiped and everything is gone, zapped.
But instead of the memory (cache? sorry..) being wiped clean,
everything I had been working on pulled up exactly as I had left it
open only minutes before..

Oh, and I would, yes, get the login screen just before it would open
on up into the previous session that theoretically maybe should not
have been there.

Oh x 2 is I don't remember which release I was using. I think maybe
Sid. If not Sid, it was Stretch testing last summer'ish (mid 2016)
because I haven't taken the laptop outside much since then

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Hibernate in stretch

[solitone]

On Wednesday, 26 July 2017 04:15:06 CEST behrad eslami wrote:
> Yes it is. its new for me. after upgrade i have these error
> 
> On Tuesday, 25 July 2017 13:13:41 CEST behrad eslami wrote:
> > Jul 23 20:23:45 laptop kernel: [  90.862717] [drm] GPU HANG: ecode
> > 9:0:0xd23b808f, in chromium [1484], reason: Hang on render ring, action:
> > reset
> > Jul 23 20:23:45 laptop kernel: [  90.862802] drm/i915: Resetting chip
> > after gpu hang

Yes, it is the same bug I have, and it has been solved with this patch:

https://patchwork.freedesktop.org/patch/111587/

> [CI,3/3] drm/i915/execlists: Reset RING registers upon resume
> There is a disparity in the context image saved to disk and our own
> bookkeeping - that is we presume the RING_HEAD and RING_TAIL match our
> stored ce->ring->tail value. However, as we emit WA_TAIL_DWORDS into the
> ring but may not tell the GPU about them, the GPU may be lagging behind
> our bookkeeping. Upon hibernation we do not save stolen pages, presuming
> that their contents are volatile. This means that although we start
> writing into the ring at tail, the GPU starts executing from its HEAD
> and there may be some garbage in between and so the GPU promptly hangs
> upon resume.

I haven't yet figured out which kernel version contains such patch, though. 
BTW, I have also submitted a bug to debian, pointing out that solution, but it 
doesn't seem to have been considered yet:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869424
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[solitone]

On Tuesday, 25 July 2017 13:13:41 CEST behrad eslami wrote:
> Jul 23 20:23:45 laptop kernel: [   90.862717] [drm] GPU HANG: ecode
> 9:0:0xd23b808f, in chromium [1484], reason: Hang on render ring, action:
> resetJul 23 20:23:45 laptop kernel: [   90.862721] [drm] GPU hangs can
> indicate a bug anywhere in the entire gfx stack, including userspace.Jul 23
> 20:23:45 laptop kernel: [   90.862722] [drm] Please file a _new_ bug report
> on bugs.freedesktop.org against DRI -> DRM/IntelJul 23 20:23:45 laptop
> kernel: [   90.862724] [drm] drm/i915 developers can then reassign to the
> right component if it's not a kernel issue.Jul 23 20:23:45 laptop kernel: [
>   90.862725] [drm] The gpu crash dump is required to analyze gpu hangs, so
> please always attach it.Jul 23 20:23:45 laptop kernel: [   90.862727] [drm]
> GPU crash dump saved to /sys/class/drm/card0/errorJul 23 20:23:45 laptop
> kernel: [   90.862802] drm/i915: Resetting chip after gpu hangJul 23
> 20:23:45 laptop kernel: [   90.862878] [drm] RC6 onJul 23 20:23:45 laptop
> kernel: [   90.880192] [drm] GuC firmware load skippedJul 23 20:23:56
> laptop kernel: [  101.832839] drm/i915: Resetting chip after gpu hang

This seems very similar to my error, isn't it?

Re: Hibernate in stretch

[Zenaan Harkness]

On Sun, Jul 23, 2017 at 09:30:30AM +0200, Hans wrote:
> The only thing, I wondered by myself, why hibernate did not stop
> the release of stretch, as everyone knew, it is badly broken.
> Maybe, hibernate is no essential package/function, that would of
> course explain it.

Perhaps your particular combination of hardware has not been tested
hibernating before and so then it's a "new" bug?

It is possible that backports kernel/ custom kernel or newer kernel
version may work better for you.. just a possibility, good luck.

Re: Hibernate in stretch

[solitone]

On Sunday, 23 July 2017 09:30:30 CEST Hans wrote:
> I do not want to mourne or cause any anger, and I do not expect it to be
> fixed at all. Remember, people do this in theire spare and free time, so we
> cannot expect, to be it fixed at all.

Well, great things have been developed in this spare and free time, so if it's 
not fixed yet the reason it's very difficult I would say.

My bug has been marked duplilcate of another, already solved. Here's the 
patch:
https://patchwork.freedesktop.org/patch/111587

How can I understand what kernel version contains this patch?
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[Joe]

On Sun, 23 Jul 2017 09:30:30 +0200
Hans  wrote:

> Am Sonntag, 23. Juli 2017, 09:15:56 CEST schrieb solitone:
> Please note, hibernate is broken since over more than 6 moths.
> After upgrading to stretch it got worse. Before upgrade, hibernating
> worked half, it hibernated, but resume crashed (after loading the
> image from swap- partition, the computer full resetted).
> 
> Now it does not even hibernate any more.
> 
> I do not want to mourne or cause any anger, and I do not expect it to
> be fixed at all. Remember, people do this in theire spare and free
> time, so we cannot expect, to be it fixed at all. 
> 
> So my solution: I do not use hibernate at the moment. If it is fixed
> some day, it will be ok, if not, it will be ok, too.
> 
> The only thing, I wondered by myself, why hibernate did not stop the
> release of stretch, as everyone knew, it is badly broken. Maybe,
> hibernate is no essential package/function, that would of course
> explain it.
> 
Unfortunately, various types of suspend are a difficult area in Linux,
as sound used to be (and still is for some people). Suspend is still a
user application, rather than something built into the OS. If you want
it to work, you have to make it work, which means you have to find out
which particular reason is stopping it from working today. Which is not
the same reason which stopped it yesterday...

I used to fix suspend sometimes, but it would take half a day, and then
software rot would cause it to fail again within a month or two, so
mostly I don't bother any more. I am using unstable, I am sure if
suspend were fixed in stable it would stay fixed, but I only use stable
on my server, which has no use for suspend.

Occasionally, I try suspend to RAM on my workstation, as an alternative
to shutting down and rebooting later, and for a period of six months or
so recently it seemed to work reliably. Then for several months, it has
appeared to suspend correctly but will not resume, only reboot. This is
suspend to *RAM*, not hibernate (and no, the swap location *is* set
correctly, but this problem started at the same time as that became an
issue, so is undoubtedly related). I have not tried for a month or so,
so maybe it is time for another try. Unstable is, of course, even more
unstable than usual this soon after a release. Perl and Python are both
uninstallable at the moment.

I have never, with Debian or some other distributions, seen any laptop
come back from any suspend. Ever. If it is not the network missing, it
is the display light which does not come on. I cannot believe it is so
difficult to turn on a backlight. Or I couldn't, until I tried
adjusting a laptop display brightness recently, and realised that some
fairly common day-to-day user requirements are still a hell of little
command-line utilities that have to be installed and then do nothing.

Give it another twenty years...

-- 
Joe

Re: Hibernate in stretch

[Hans]

Am Sonntag, 23. Juli 2017, 09:15:56 CEST schrieb solitone:
Please note, hibernate is broken since over more than 6 moths.
After upgrading to stretch it got worse. Before upgrade, hibernating worked 
half, it hibernated, but resume crashed (after loading the image from swap-
partition, the computer full resetted).

Now it does not even hibernate any more.

I do not want to mourne or cause any anger, and I do not expect it to be fixed 
at all. Remember, people do this in theire spare and free time, so we cannot 
expect, to be it fixed at all. 

So my solution: I do not use hibernate at the moment. If it is fixed some day, 
it will be ok, if not, it will be ok, too.

The only thing, I wondered by myself, why hibernate did not stop the release 
of stretch, as everyone knew, it is badly broken. Maybe, hibernate is no 
essential package/function, that would of course explain it.

Have a nice day, and happy hacking!

Best

Hans 
> On Sunday, 23 July 2017 08:58:41 CEST solitone wrote:
> > I'll file a new bug on bugs.freedesktop.org, since there are no open bugs
> > on that.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=101884

Re: Hibernate in stretch

[solitone]

On Sunday, 23 July 2017 08:58:41 CEST solitone wrote:
> I'll file a new bug on bugs.freedesktop.org, since there are no open bugs on
> that.
https://bugs.freedesktop.org/show_bug.cgi?id=101884
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[solitone]

On Sunday, 23 July 2017 02:54:06 CEST behrad eslami wrote:
> I guess this is VGA kernel driver bug but i cant resolv it
> https://lists.debian.org/debian-kernel/2017/02/msg00210.html
> https://lists.debian.org/debian-kernel/2017/02/msg00211.html
> [3.100956] [drm] Finished loading i915/skl_dmc_ver1_26.bin (v1.26)[  
>  3.108246] [drm] GuC firmware load skipped

I've just tried again, and (after some time) I get the graphical login screen, 
but it's not functional. I can login from a virtual console, though.

I also have issues with my graphics processing unit. These are the messages 
that the kernel logs:

Jul 23 08:00:10 alan kernel: [drm] GPU HANG: ecode 8:0:0x980e800f, in 
kscreenlocker_g [27962], reason: Hang on render ring, action: reset
Jul 23 08:00:10 alan kernel: [drm] GPU hangs can indicate a bug anywhere in 
the entire gfx stack, including userspace.
Jul 23 08:00:10 alan kernel: [drm] Please file a _new_ bug report on 
bugs.freedesktop.org against DRI -> DRM/Intel
Jul 23 08:00:10 alan kernel: [drm] drm/i915 developers can then reassign to 
the right component if it's not a kernel issue.
Jul 23 08:00:10 alan kernel: [drm] The gpu crash dump is required to analyze 
gpu hangs, so please always attach it.
Jul 23 08:00:10 alan kernel: [drm] GPU crash dump saved to /sys/class/drm/
card0/error
Jul 23 08:00:10 alan kernel: drm/i915: Resetting chip after gpu hang
Jul 23 08:00:21 alan kernel: drm/i915: Resetting chip after gpu hang
Jul 23 08:00:32 alan kernel: drm/i915: Resetting chip after gpu hang
Jul 23 08:00:43 alan kernel: drm/i915: Resetting chip after gpu hang

I'll file a new bug on bugs.freedesktop.org, since there are no open bugs on 
that.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[solitone]

On Thursday, 20 July 2017 02:28:32 CEST behrad eslami wrote:
> I increase swap and have same problem yet. 

Did you increased the swap partition, or are you using a swap file?
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[solitone]

On my previous laptop with jessie hibernation didn't work. On my current 
laptop with stretch hibernation doesn't work either.

During the several updates that interested stretch in the last few months, the 
symptoms changed, and I don't remember exactly their evolution at the moment. 
Currently, when the system resumes, after a few boot messages, everthing 
stalls on a black screen. I don't even get the login screen.

On Tuesday, July 18, 2017, 8:20:34 AM GMT+4:30, Lck Ras  
wrote:
> Are you sure you have enough swap space? You generally need 1.5x your
> total memory if order to hibernate safely.

1,5x? I thought 1x would be enough:

~$ free -m
  totalusedfree  shared  buff/cache  available
Mem:   789039061358 6112625   3070
Swap:  7629   07629
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁Sent from my brain using neurons fueled by glucose.
⢿⡄⠘⠷⠚⠋⠀ 
⠈⠳⣄

Re: Hibernate in stretch

[Michael Biebl]

Am 18.07.2017 um 05:02 schrieb behrad eslami:
> Hi 
> 
> Im installed stretch in thinkpad x260 and hibernate not work corrctly.
> When poweron laptop, resume hibernated desktop and suddeny go to the
> display manager and after login all application was closed
> 
> Graphical enviroment:
> i3
> lightdm
> tlp tlp-rdw tp-smapi-dkms acpi-call-dkms postfix (power saving)
> 
> Thanks 

Have you checked if
/etc/initramfs-tools/conf.d/resume
matches your swap partition? See /dev/disk/by-uuid/

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Hibernate in stretch

[behrad eslami]

Hi
Thanks for your answer. My free command output$ free -m
  totalusedfree  shared  buff/cache   available
Mem:   7871 9956107  88 7686548
Swap:  7628   07628

Cant i add swap file for increase swap and this problem? I dont have this 
problem in jessie.

On Tuesday, July 18, 2017, 8:20:34 AM GMT+4:30, Lck Ras  
wrote:

On 07/18/2017 12:02 PM, behrad eslami wrote:
> Im installed stretch in thinkpad x260 and hibernate not work corrctly. When 
> poweron laptop, resume hibernated desktop and suddeny go to the display 
> manager and after login all application was closed
> Graphical enviroment:i3lightdmtlp tlp-rdw tp-smapi-dkms acpi-call-dkms 
> postfix (power saving)
> Thanks 

Are you sure you have enough swap space? You generally need 1.5x your
total memory if order to hibernate safely.