Bug#841712: systemd: Display black on resume from suspend

2017-01-11 Thread Michael Biebl
On Sat, 22 Oct 2016 22:59:25 +0200 Michael Biebl  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?


-- 
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


Bug#841712: systemd: Display black on resume from suspend

2016-10-22 Thread Michael Biebl
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)



-- 
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


Bug#841712: systemd: Display black on resume from suspend

2016-10-22 Thread 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.



What does
cat /sys/power/disk
cat /sys/power/state
say?


# cat /sys/power/disk
[platform] shutdown reboot suspend
# cat /sys/power/state
freeze mem disk


Do you have a /etc/systemd/sleep.conf or  /etc/systemd/sleep.conf.d/* files?


No, neither.




[1] https://github.com/systemd/systemd/blob/master/src/sleep/sleep.c




Bug#841712: systemd: Display black on resume from suspend

2016-10-22 Thread Michael Biebl
Am 22.10.2016 um 18:23 schrieb Bill Gribble:
> To answer your question in the other followup, yes, I made a mistake
> titling this bug.
> This is a hibernate-related problem, not suspend.
> 
> On 10/22/2016 11:12 AM, Michael Biebl wrote:
>> This is what "systemctl hibernate" uses.
>> Can you run this command and see if that works?
> 
> "systemctl hibernate", as either root or a non-root user, resumes with
> black display.
> 
> "echo disk > /sys/power/state" (works only as root) resumes with
> functioning display.

Does /lib/systemd/systemd-sleep hibernate
work?

What does
cat /sys/power/disk
cat /sys/power/state
say?

The systemd-sleep binary does nothing fancy, as you can see at [1]
So if that command fails, but "echo disk > /sys/power/state" isn't, then
I'm a bit at a loss here.

Do you have a /etc/systemd/sleep.conf or  /etc/systemd/sleep.conf.d/* files?


[1] https://github.com/systemd/systemd/blob/master/src/sleep/sleep.c
-- 
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


Bug#841712: systemd: Display black on resume from suspend

2016-10-22 Thread Bill Gribble
To answer your question in the other followup, yes, I made a mistake 
titling this bug.

This is a hibernate-related problem, not suspend.

On 10/22/2016 11:12 AM, Michael Biebl wrote:

This is what "systemctl hibernate" uses.
Can you run this command and see if that works?


"systemctl hibernate", as either root or a non-root user, resumes with 
black display.


"echo disk > /sys/power/state" (works only as root) resumes with 
functioning display.



Having "pm-utils" installed is no longer recommended fwiw. I would
uninstall it. Do you have other packages like
"laptop-mode-tools" or "hibernate" installed, which might interfere?


I had pm-utils and laptop-mode-tools installed.  I've purged them; no 
difference.

Do you have any custom hooks in
/lib/systemd/system-sleep/ ?


Nothing custom, just the packager-supplied ones from "hdparm" and 
"network-manager"



What's the output of systemctl show hibernate.target


Id=hibernate.target
Names=hibernate.target
Wants=anacron-resume.service
BindsTo=systemd-hibernate.service
Before=anacron-resume.service
After=systemd-hibernate.service
Documentation=man:systemd.special(7)
Description=Hibernate
LoadState=loaded
ActiveState=inactive
SubState=dead
FragmentPath=/lib/systemd/system/hibernate.target
UnitFileState=static
UnitFilePreset=enabled
StateChangeTimestampMonotonic=0
InactiveExitTimestampMonotonic=0
ActiveEnterTimestampMonotonic=0
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=yes
CanStop=yes
CanReload=no
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=no
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=no
AssertResult=no
ConditionTimestampMonotonic=0
AssertTimestampMonotonic=0
Transient=no
StartLimitIntervalSec=1000
StartLimitBurst=5
StartLimitAction=none



Bug#841712: systemd: Display black on resume from suspend

2016-10-22 Thread Michael Biebl
Am 22.10.2016 um 16:35 schrieb Bill Gribble:
> 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.

I assume the subject of this bug report is incorrect, which talks about
suspend, which is typically meant as suspend-to-ram whereas hibernate is
usually referred to as suspend-to-disk.


-- 
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


Bug#841712: systemd: Display black on resume from suspend

2016-10-22 Thread Michael Biebl
Control: severity -1 + moreinfo

Am 22.10.2016 um 16:35 schrieb Bill Gribble:
> 
> 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

This is what "systemctl hibernate" uses.

Can you run this command and see if that works?

>  * "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

Having "pm-utils" installed is no longer recommended fwiw. I would
uninstall it. Do you have other packages like
"laptop-mode-tools" or "hibernate" installed, which might interfere?
If so, can you purge them and try again?
Do you have any custom hooks in
/lib/systemd/system-sleep/ ?
If so, can you attach them to this bug report please.

What's the output of systemctl show hibernate.target
-- 
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


Bug#841712: systemd: Display black on resume from suspend

2016-10-22 Thread Bill Gribble

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  libapparmor12.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  libidn111.33-1
ii  libip4tc0   1.6.0-4
ii  libkmod222-1.1
ii  liblzma55.2.2-1.2
ii  libmount1   2.28.2-1
ii  libpam0g1.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  dbus1.10.12-1
ii  libpam-systemd  231-9

Versions of packages systemd suggests:
ii  policykit-10.105-16
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
ii  udev  231-9

-- no debconf information