[solved] systemd (& KDE) suspend, resume fails with black/blank screen

roepi · 2015-08-09 12:20:21

Hi. On a Dell Latitude E6430 resume from suspend-to-ram does not work (~ it never really did), neither doing systemctl suspend nor suspend from KDE environment; the screen just stays black, and this is also true for all virtual terminals.
Setting is Dell Latitude E6430 latest BIOS, NVIDIA Corporation GF108GLM [NVS 5200M], Optimus switched off (= no Intel VGA), running latest Nouveau driver, KDE 4 Plasma Desktop. Laptop is most times docked, two monitors connected via mini display port, but this also happens when laptop is undocked. Running is the latest mainline kernel (4.1.4), but it never really worked with the previous kernels as well.
With regards to Suspend/hibernate doesn't work I also tried the LTS kernel 3.14, but no change, same error.
With regards to Blank screen when waking from suspend I disabled SpeedStep and/or VT I/O in the BIOS, but no change, same error.
With regards to this thread systemd: Resume sometimes fails (=> blank screen) I installed and uninstalled Laptop Mode Tools, acpid and TLP, but no change, same error.

In systemd/journal I did not find anything, it just says suspend, and the rest is silence...

Aug 09 13:15:45 stupendous polkitd[726]: Registered Authentication Agent for unix-process:1705:21204 (system bus name :1.47 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Aug 09 13:15:45 stupendous NetworkManager[665]: <info>  sleep requested (sleeping: no  enabled: yes)
Aug 09 13:15:45 stupendous NetworkManager[665]: <info>  sleeping...
Aug 09 13:15:45 stupendous NetworkManager[665]: <info>  (wlp3s0): device state change: unavailable -> unmanaged (reason 'sleeping') [20 10 37]
Aug 09 13:15:45 stupendous kernel: IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
Aug 09 13:15:45 stupendous NetworkManager[665]: <info>  NetworkManager state is now ASLEEP
Aug 09 13:15:45 stupendous polkitd[726]: Unregistered Authentication Agent for unix-process:1705:21204 (system bus name :1.47, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Aug 09 13:15:45 stupendous systemd[1]: Reached target Sleep.
Aug 09 13:15:45 stupendous systemd[1]: Starting Suspend...
-- Reboot --
Aug 09 13:18:57 localhost systemd-journal[85]: Runtime journal (/run/log/journal/) is currently using 8.0M.
                                               Maximum allowed usage is set to 799.5M.
                                               Leaving at least 1.1G free (of currently available 7.8G of space).
                                               Enforced usage limit is thus 799.5M.
Aug 09 13:18:57 localhost systemd-journal[85]: Runtime journal (/run/log/journal/) is currently using 8.0M.
                                               Maximum allowed usage is set to 799.5M.
                                               Leaving at least 1.1G free (of currently available 7.8G of space).
                                               Enforced usage limit is thus 799.5M.
Aug 09 13:18:57 localhost kernel: microcode: CPU0 microcode updated early to revision 0x1b, date = 2014-05-29
Aug 09 13:18:57 localhost kernel: Initializing cgroup subsys cpuset
Aug 09 13:18:57 localhost kernel: Initializing cgroup subsys cpu
Aug 09 13:18:57 localhost kernel: Initializing cgroup subsys cpuacct
Aug 09 13:18:57 localhost kernel: Linux version 4.1.4-1-ARCH (builduser@foutrelis) (gcc version 5.2.0 (GCC) ) #1 SMP PREEMPT Mon Aug 3 21:30:37 UTC 2015
Aug 09 13:18:57 localhost kernel: Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=36050399-65ac-4ff6-98a0-866f43bc28ed rw rd.luks.uuid=c02dccab-154b-400f-a9d7-596a61ab40c4 fbcon=scrollback:4096k
Aug 09 13:18:57 localhost kernel: e820: BIOS-provided physical RAM map:

Anyone with similar settings and with/without this problem? Any hint what I should investigate next is very appreciated. Regards.

Last edited by roepi (2016-12-20 22:33:37)

roepi · 2015-10-01 07:46:48

Even though this question seems to be a tumbleweed question, some additions observed. Update to Plasma 5 (5.4.1) did bring no change, still same error. If going into a virtual terminal, stopping KDE/SDDM and doing systemctl suspend I get the same error, no resume possible, Laptop screen is black, no hard disk activity. So the error seems not connected to the desktop environment.
I cross-checked with Linux Mint 17.2 KDE live boot, resume from suspend works fine; but Mint KDE is known to run on Kernel 3.16 and no systemd; so it hardly compares, but suspend is basically working on this Notebook.

akiva_ · 2015-10-09 18:57:31

I, too, have been struggling with this. I am not using any power manager like KDE, only bspwm, but I have tried tinkering with everything from _systemd logind_ settings, _acpi_ and _acpid_, as well as laptop-mode-tools (these are the only tools I have installed for managing power on my Dell XPS 15 (mid-2012 model). It's extremely frustrating. On top of this, basic `systemctl poweroff` hangs before doing the final shutdown and `systemctl reboot` shuts down rather than reboots.

I would love to see some input on resolving this recorded here for anyone else struggling for solutions online or in IRC (both of which, for me, has lead nowhere).

EDIT: To clarify, I am referring to suspending to RAM, as I do not have a swap partition.

Last edited by akiva_ (2015-10-09 18:59:05)

josephk · 2015-11-09 12:28:10

same problem here.. can't suspend anymore becaue when machine (intel broadwell) wakes up freezes with black screen.

problem appeared some two weeks ago, maybe related to updating mesa or kernel to a point release.. dunno.

wonderful state of Linux for 2016..

akiva_ · 2015-11-09 18:29:44

I was told this issue is likely related to the kernel support for the device in question. This seems to mirror the sentiment here: https://wiki.archlinux.org/index.php/Po … n.27t_work , which is highly disappointing. Does anyone know if this seems to be the root cause for our issue(s)? If so, is there some known fix for the kernel in the works?

josephk · 2015-11-09 19:34:41

yes, downgrading to lts kernel solved the problem.
I think I encountered the problem after a kernel 4.2.x point release, maybe 4.2.3 or 4.2.4 since package was moved into [core] as 4.2.2 if I'm not wrong

Last edited by josephk (2015-11-09 19:35:40)

akiva_ · 2015-11-09 19:39:07

I think that this issue has affected me more a few months now, though, so it's likely older than that for me. Which version did you downgrade to? I certainly hope an issue as serious as this is resolved soon.

josephk · 2015-11-09 19:52:21

linux-lts-4.1.12 as in the [core] repo.
no, to me for sure this problem appeared two max max three weeks ago. definitely linux 4.2 serie.

cfr · 2015-11-09 23:23:05

roepi wrote:

Aug 09 13:15:45 stupendous systemd[1]: Reached target Sleep.
Aug 09 13:15:45 stupendous systemd[1]: Starting Suspend...

It is strange that nothing appears after this. Is this because literally nothing happens or because stuff just isn't logged? By way of contrast, I have a *lot* of stuff happening after this (prior to a successful resume). The first such message is just

systemd-sleep[7049]: Suspending system...

It seems weird that you don't even have that much - even if things go haywire when the kernel starts doing things to file systems and so on. systemd-sleep doesn't have an independent existence of its own, as far as I can tell.

Do you get any more information by calling the suspend target directly, for example?

roepi · 2015-12-05 00:43:13

I pasted two journald logs.

The First is from the system going into suspend after some time by power management. It seems like kscreen/kscreenlocker have trouble when monitors are off (suspended or not available), core dump crash.

journald log - power management suspend

The other log is from a simple call

systemctl suspend

journald log - systemctl suspend.

I submitted the command at 01:22, as you can see not much in there.

In both cases the screens stay blank/black, and all I can do is press the power button for some time for a hard reboot.

roepi · 2015-12-13 22:25:18

Cross check with the latest archiso. I booted into the console and called systemctl suspend. The system went into suspend and woke up without problems, this is the relevant archiso journald log.
I booted my system, opened a console (virtual terminal), stopped sddm and called systemctl suspend. System does not wake up properly, see this thread.

So the good news for the Arch and Linux community, it does not seem to be a bug in Arch Linux or upstream but this is bad news for me.

Somehow my system is busted, but I have no idea what is wrong. Reinstall could be the last resort, but as of now I would like to avoid this.

akiva_ · 2016-01-21 18:08:01

I agree with the sentiment. At first I thought it somehow was due to this system having a different setup than my others (dm-crypt on LUKS), which made little sense, but I've altered nothing else. I would love to solve this without a reinstall solely due to my lack of experience in solving it directly.

firekage · 2016-01-21 19:00:26

josephk wrote:

same problem here.. can't suspend anymore becaue when machine (intel broadwell) wakes up freezes with black screen.
problem appeared some two weeks ago, maybe related to updating mesa or kernel to a point release.. dunno.
wonderful state of Linux for 2016..

In fact, i have problems with suspend to ram, or suspend to disk from the beginning my way with Arch. On Ubuntu and Slackware it always worked, especially on Slackware.

My topic
https://bbs.archlinux.org/viewtopic.php?id=207730

I did too many thing, but it just randomly fails with blocked screen, black screen. Three times in a row i can suspend, fourth one crash, i have error in calltraces, but tried to check what they meant, and did not found anything useful.

Yes, this is one of the features that i need...but i know that oftem it could be problem with bioses...

Tried downgrading kernel, nvidia - the same.

Last edited by firekage (2016-01-21 19:01:12)

roepi · 2016-12-20 22:33:17

The latest Dell Latitude E6430 BIOS A18 has a new option Power Management -> Block Sleep (S3 State). If you activate this option, resume is working again. Not a real solution, I grant, as Power Saving only goes into state S1 - CPU Stopped, that consumes more power than S3 – Suspend to RAM; however it resolve the resume fail with black screen.
I mark this thread as solved to get it from the shelve.

Arch Linux

#1 2015-08-09 12:20:21

[solved] systemd (& KDE) suspend, resume fails with black/blank screen

#2 2015-10-01 07:46:48

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#3 2015-10-09 18:57:31

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#4 2015-11-09 12:28:10

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#5 2015-11-09 18:29:44

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#6 2015-11-09 19:34:41

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#7 2015-11-09 19:39:07

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#8 2015-11-09 19:52:21

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#9 2015-11-09 23:23:05

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#10 2015-12-05 00:43:13

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#11 2015-12-13 22:25:18

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#12 2016-01-21 18:08:01

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#13 2016-01-21 19:00:26

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

#14 2016-12-20 22:33:17

Re: [solved] systemd (& KDE) suspend, resume fails with black/blank screen

Board footer