On Wed, 24 Jan 2018 08:40:55 -0700 InvalidPath <invalid.path@xxxxxxxxx> wrote: > On Wed, Jan 24, 2018 at 7:59 AM, InvalidPath <invalid.path@xxxxxxxxx> > wrote: > > > > > > So last night I suspended using 'sudo systemctl suspend' At around > 8pm. This morning when I opened the lid I was greeted with a black > screen but responsive keyboard led's.. not sure what happened there > but I had to hold the power button to shut down then boot it back up. Can you still switch to a working console/tty? If yes: You might be able to cleanly shut down. And some side note (I'll come to the sleep issue farther down): If your tty's are black as well I recommend - instead of a hard shutdown - to try to enable your sysrq keys: with them enabled you can stop running processes, umount partitions and then often (not always) cleanly shut down - if you didn't do it so far: https://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/sysrq.txt or some html: https://www.kernel.org/doc/html/v4.11/admin-guide/sysrq.html My magic key combo (you might have a different one - see docs above): on a tty: 0 Press <alt> and keep holding ... 1 Press <fn>+<print> keys. Keep holding both, then release these two 2 Press some some sysrq key -- release it 3 Only now release <alt> now You can check on a console whether sysrq keys are enabled by pressing 'h' (for help messages) in step 2 .... > Checking Journalctl I see that it appears the laptop went down like it > should have last night. Then at 7:55 today fired up but I'm having > trouble finding the culprit here. > > https://paste.fedoraproject.org/paste/HkXlIu3muElfgUEXjlBh5g The kernel seems to be fine: I see in those logs that the S3 sleep¹ was triggered successfully, as it seems, both for sleep mode and for waking up - and it looks very similar to my own logs, i.e. logs for a system that suspends to RAM rather reliably. Your logs: Jan 23 20:41:04 Vostok systemd[1]: Reached target Sleep. Jan 23 20:41:04 Vostok systemd[1]: Starting Suspend... Jan 23 20:41:04 Vostok systemd-sleep[24988]: Suspending system... Jan 23 20:41:04 Vostok kernel: PM: suspend entry (deep) ... Jan 24 07:53:26 Vostok kernel: PM: suspend devices took 1.173 seconds Jan 24 07:53:26 Vostok kernel: ACPI: Preparing to enter system sleep state S3 (I'd ignore the wrong times last lines: happens on my system too: the log obviously only finishes for the event after wake up ...) .... an 24 07:53:26 Vostok kernel: ACPI: Waking up from system sleep state S3 Jan 24 07:53:26 Vostok kernel: ACPI: EC: event unblocked The culprit seems to be X: Jan 24 07:53:27 Vostok kscreenlocker_greet[24921]: The X11 connection broke: I/O error (code 1 See lines 413 --> 441 on your pasteb. log. Also please note this log snippet: /usr/libexec/gdm-x-session[17556]: (EE) Please also check the log file at "/home/bhart/.local/share/xorg/Xorg.0.log" for additional information. To learn what's up maybe stop X completely: no gdm, no gdm-x-session, no nothing related stuff (not sure if this works nowadays) and then close your lid, press the sleep button or whatever, and then try to wake up the system. Even better: reboot with X disabled (no idea how to do it) and then same procedure as before: sleep, then wake up .... Regards, Wolfgang 1 https://www.kernel.org/doc/Documentation/power/states.txt _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
