Your message dated Mon, 22 May 2017 15:57:15 +0200
with message-id <[email protected]>
and subject line Re: Bug#841712: systemd: Display black on resume from suspend
has caused the Debian Bug report #841712,
regarding systemd: Display black on resume from hibernate
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
841712: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841712
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 231-9
Severity: normal
My machine is a 4-year-old Dell E6430. It's worked flawlessly with
hibernate
and suspend-to-ram for years. Recently (sometime in Summer 2016) the
display
started going black at the point of resume-from-hibernate when the GUI
should
appear.
I am entering hibernate by pressing the power button, which I have mapped to
the "hibernate" action in Gnome. I believe this uses the systemd hibernate
action.
No combination of switching VTs, keyboard/mouse input, or anything else
can get
the display on when it is in this state.
I know the system has resumed, because if I close the laptop lid to
suspend-to-
ram and then open again the display lights up properly and I'm back where I
should be.
I have hibernated the system using other means with differing results:
* "echo disk > /sys/power/state" hibernates and resumes successfully with
active display after resume
* "pm-hibernate" with no quirks behaves exactly like the power-button
action
(display black on resume)
* "pm-hibernate --quirk-dpms-on" hibernates and resumes properly
-- Package-specific info:
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii adduser 3.115
ii libacl1 2.2.52-3
ii libapparmor1 2.10.95-5
ii libaudit1 1:2.6.7-1
ii libblkid1 2.28.2-1
ii libc6 2.24-5
ii libcap2 1:2.25-1
ii libcryptsetup4 2:1.7.2-4
ii libgcrypt20 1.7.3-2
ii libgpg-error0 1.24-1
ii libidn11 1.33-1
ii libip4tc0 1.6.0-4
ii libkmod2 22-1.1
ii liblzma5 5.2.2-1.2
ii libmount1 2.28.2-1
ii libpam0g 1.1.8-3.3
ii libseccomp2 2.3.1-2
ii libselinux1 2.5-3
ii libsystemd0 231-9
ii mount 2.28.2-1
ii util-linux 2.28.2-1
Versions of packages systemd recommends:
ii dbus 1.10.12-1
ii libpam-systemd 231-9
Versions of packages systemd suggests:
ii policykit-1 0.105-16
pn systemd-container <none>
pn systemd-ui <none>
Versions of packages systemd is related to:
ii udev 231-9
-- no debconf information
--- End Message ---
--- Begin Message ---
On Thu, 12 Jan 2017 03:16:47 +0100 Michael Biebl <[email protected]> wrote:
> On Sat, 22 Oct 2016 22:59:25 +0200 Michael Biebl <[email protected]> wrote:
> > Am 22.10.2016 um 22:46 schrieb Bill Gribble:
> > > On 10/22/2016 02:13 PM, Michael Biebl wrote:
> > >>
> > >> Does /lib/systemd/systemd-sleep hibernate
> > >> work?
> > >
> > > Ah, interesting! That works fine, display resumes as expected. Works
> > > only as root.
> >
> > This is exactly the command that is used by systemd-hibernate.service.
> > The only difference afaics is, that systemctl hibernate will signal
> > systemd-logind and logind sends out signals to other programs via D-Bus.
> > Those then can react on the suspend/hibernate request.
> >
> > So, my guess is, that it's not actually systemd which causes this, but
> > some other program that reacts on that logind signal.
> >
> > Those would typically be X itself and programs listed by systemd-inhibit.
> >
> > I assume if you boot into a non-graphical login (say via single on the
> > grub command line), then systemctl hibernate works as well?
> >
> > I would try a minimal X session next, where systemd-inhibit does not
> > list any programs. If that fails, then it sounds like an X problem.
> >
> > Check the X related log messages in journal (if you have ssh access,
> > that should be no problem)
>
> Any news here?
Since I didn't hear back from you, I'm closing this bug report.
As explained, it's most likely not a bug in systemd anyway but caused by
something which listens/reacts to logind events.
Regards,
Michael
--
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
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
