System fails to suspend, goes black screen and unresponsive sometimes.

yanom · 2017-04-28 03:47:21

I have an Arch desktop with this motherboard and a GeForce GTX 750Ti graphics card with proprietary nvidia drivers. I'm currently using the linux-lts kernel.

Sometimes (like 1/10 of the time) when I do

 systemctl suspend

to put the computer to sleep, instead of going to sleep normally, the screen goes black, it becomes unresponsive to all input, and the system does not go into a low power state (fans continue running and the power light does not start blinking like it should). The only way I've found to get out of this is to hard reset the computer.

Does anyone know how to fix or diagnose this problem? It's driving me crazy.

Last edited by yanom (2017-04-28 03:47:40)

jasonwryan · 2017-04-28 03:57:50

Read the journal for the previous boot when you restart.

Moving to NC...

yanom · 2017-05-05 20:41:48

jasonwryan wrote:

Read the journal for the previous boot when you restart.

Ok, it happened again, and I got the log of the last boot using

 # journalctl --boot=-1

.

The last few lines of the log (in the minutes leading up to the crash) are this:

May 05 11:18:22 earth dhcpcd[419]: enp2s0: hardware address f0:29:29:5d:e5:b4 claims 134.173.61.117
May 05 11:18:49 earth dhcpcd[419]: enp2s0: hardware address 3c:5e:c3:44:66:b1 claims 134.173.61.117
May 05 11:18:52 earth dhcpcd[419]: enp2s0: hardware address 3c:5e:c3:2c:1e:b1 claims 134.173.61.117
May 05 11:18:52 earth dhcpcd[419]: enp2s0: hardware address f0:29:29:5d:e5:b4 claims 134.173.61.117
May 05 11:19:02 earth systemd[453]: Time has been changed
May 05 11:19:02 earth systemd[1]: Time has been changed
May 05 11:19:19 earth dhcpcd[419]: enp2s0: hardware address 3c:5e:c3:44:66:b1 claims 134.173.61.117
May 05 11:19:21 earth dhcpcd[419]: enp2s0: hardware address f0:29:29:5d:e5:b4 claims 134.173.61.117
May 05 11:19:22 earth dhcpcd[419]: enp2s0: hardware address 3c:5e:c3:2c:1e:b1 claims 134.173.61.117
May 05 11:20:12 earth dhcpcd[419]: enp2s0: hardware address 3c:5e:c3:2c:1e:b1 claims 134.173.61.117
May 05 11:20:12 earth dhcpcd[419]: enp2s0: hardware address 3c:5e:c3:44:66:b1 claims 134.173.61.117
May 05 11:20:13 earth dhcpcd[419]: enp2s0: hardware address f0:29:29:5d:e5:b4 claims 134.173.61.117
May 05 11:20:16 earth polkitd[544]: Registered Authentication Agent for unix-process:1958:495696 (system bus name :1.1182 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
May 05 11:20:16 earth systemd[1]: Reached target Sleep.
May 05 11:20:16 earth systemd[1]: Starting Suspend...
May 05 11:20:16 earth polkitd[544]: Unregistered Authentication Agent for unix-process:1958:495696 (system bus name :1.1182, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)

I have the whole log here .

Is this here enough to diagnose the problem? Anyone know what's wrong here?

seth · 2017-05-06 07:41:59

Wild Guesses:
a) https://wiki.archlinux.org/index.php/Microcode
b) Syncthing (some stalled I/O)

Morn · 2017-05-06 09:28:13

I've encountered this partial shutdown issue when using a USB DVB-C stick a few years ago, even when I had unplugged the stick before suspending the machine. Maybe that stick messed with the PC's internal USB hub somehow so it could not enter a low-power state.

So maybe try to remove all unnecessary USB devices and reboot and see if that changes anything.

yanom · 2017-05-06 09:54:35

a) https://wiki.archlinux.org/index.php/Microcode

I have an AMD processor, so according to the wiki I don't have any relevant microcode updates

...USB DVB-C stick a few years ago, even when I had unplugged the stick before suspending the machine.

It could be USB related... although the crash happens even during boots when I don't plug in any flash drives.

b) Syncthing (some stalled I/O)

That's the most likely culprit of what people have mentioned. Does anyone know how I could test this hypothesis and maybe fix the problem? I use Syncthing to store all of my work and sync it with my laptop, so I can't really turn it off and run for days waiting for a crash to fail to happen.

seth · 2017-05-06 13:06:07

Before going to sleep, check whether the process (or any) is waiting for I/O (indicated by a "D" in ps)
If it is, rather don't attempt to STR (until the condition is gone, you cannot kill the process in any way at this point) - or if you try, prepare for failure.
Otherwise, try to SIGSTOP the process before and SIGCONT it after the STR

yanom · 2017-05-09 06:29:34

seth wrote:

Before going to sleep, check whether the process (or any) is waiting for I/O (indicated by a "D" in ps)

Hm, that sounds like it could be the problem. Is there anyway to check for this programmatically and then be able to write a wrapper script for "systemctl suspend" that will decline to put me in suspend if there is a process waiting for IO?

seth · 2017-05-09 07:13:52

ps --no-headers -o state,pid,cmd -A | grep -E '^[^[:space:]]*D[^[:space:]]*\s'

yanom · 2017-05-10 08:08:03

seth wrote:

ps --no-headers -o state,pid,cmd -A | grep -E '^[^[:space:]]*D[^[:space:]]*\s'

Ah, thanks! I wrote a script to check the output of that command and only suspend if it's empty. I'll see if this fixes the problem.

yanom · 2017-05-15 00:09:34

yanom wrote:

seth wrote:
ps --no-headers -o state,pid,cmd -A | grep -E '^[^[:space:]]*D[^[:space:]]*\s'
Ah, thanks! I wrote a script to check the output of that command and only suspend if it's empty. I'll see if this fixes the problem.

Update - the problem is not fixed. I had the system hang again despite the script checking for stalled IO. And once again I didn't add or remove any USB devices recently.

Anyone have any other leads on what the problem might be?

glitsj16 · 2017-05-15 08:21:09

Hi yanom. You could try this shell script to get more detailed debug info when suspend fails:

#!/bin/sh
#
# debug systemd sleep

MAINUSER="$(awk -F: '$3==1000{print $1}' /etc/passwd)"

if [ -x /lib/systemd/systemd-sleep ]; then
    /lib/systemd/systemd-sleep suspend > /dev/null 2>&1
    if [ $? -ne 0 ]; then
	sudo -u "$MAINUSER" dmesg -T | grep Freez -A4 > /home/"$MAINUSER"/systemd-sleep.log
    fi
fi

The script assumes your regular user is 1000, adjust accordingly if this is not your case. Save it somewhere on your PATH & run it with sudo instead of calling `systemctl suspend`.

Goodluck

yanom · 2017-05-19 07:21:11

glitsj16 wrote:

Hi yanom. You could try this shell script to get more detailed debug info when suspend fails:
#!/bin/sh
#
# debug systemd sleep

MAINUSER="$(awk -F: '$3==1000{print $1}' /etc/passwd)"

if [ -x /lib/systemd/systemd-sleep ]; then
    /lib/systemd/systemd-sleep suspend > /dev/null 2>&1
    if [ $? -ne 0 ]; then
	sudo -u "$MAINUSER" dmesg -T | grep Freez -A4 > /home/"$MAINUSER"/systemd-sleep.log
    fi
fi
The script assumes your regular user is 1000, adjust accordingly if this is not your case. Save it somewhere on your PATH & run it with sudo instead of calling `systemctl suspend`.
Goodluck

I saved your script and started doing that to suspend. I had the suspend fail again, but no systemd-sleep.log file was produced. What does this tell us?

seth · 2017-05-19 10:08:54

Nothing - you fail to S3 itfp; you subsequently fail to wake up from S3, so whatever you'd execute after resume from S3 is of course never reached.

Stupid question: does "dmesg | grep NVRM" warn you about an unsupported framebuffer console?
In case and if you follow https://wiki.archlinux.org/index.php/GR … ramebuffer - does the screen still turn black in this case or do you get a console with some debug output? Also ensure to not boot "quiet" for this to work

yanom · 2017-05-21 16:49:40

seth wrote:

Stupid question: does "dmesg | grep NVRM" warn you about an unsupported framebuffer console?

Looks like you're on to something here! :

[root@earth jacob]# dmesg | grep NVRM
[    5.954618] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  381.22  Thu May  4 00:55:03 PDT 2017 (using threaded interrupts)
[   55.340097] NVRM: Your system is not currently configured to drive a VGA console
[   55.340099] NVRM: on the primary VGA device. The NVIDIA Linux graphics driver
[   55.340100] NVRM: requires the use of a text-mode VGA console. Use of other console
[   55.340101] NVRM: drivers including, but not limited to, vesafb, may result in
[   55.340102] NVRM: corruption and stability problems, and is not supported.

In case and if you follow https://wiki.archlinux.org/index.php/GR … ramebuffer - does the screen still turn black in this case or do you get a console with some debug output? Also ensure to not boot "quiet" for this to work

This looks like something that would help, but I'm using Syslinux to boot this machine and don't have GRUB. Do you know what I should tweak in that case? I'm also not booting in "quiet" mode.

seth · 2017-05-21 20:13:45

idk, sorry - but https://wiki.archlinux.org/index.php/Sy … _boot_menu along passing eg. "vga=786" might work.

Ropid · 2017-05-21 20:47:01

There was something about UEFI and using a graphics card that does not have firmware for UEFI, instead the old-school firmware for BIOS that's accessed through the CSM that the UEFI has for BIOS compatibility. I think I saw someone from NVIDIA write that those warning messages in the kernel log are unavoidable with that setup.

EDIT: Here's that post I meant:

https://devtalk.nvidia.com/default/topi … mplaints-/

Last edited by Ropid (2017-05-21 20:55:32)

yanom · 2017-06-13 15:13:20

Ack, the problem is back! I set "vga=786" in my kernel command options, and the black screen problem didn't happen for a few weeks so I thought it was fixed, but it's not.

Seems likely the problem is due to my NVIDIA card. Is it possible to somehow unload the nvidia driver prior to suspend and reload it on waking? Or can you not just disconnect a graphics card driver like that.

Arch Linux

#1 2017-04-28 03:47:21

System fails to suspend, goes black screen and unresponsive sometimes.

#2 2017-04-28 03:57:50

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#3 2017-05-05 20:41:48

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#4 2017-05-06 07:41:59

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#5 2017-05-06 09:28:13

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#6 2017-05-06 09:54:35

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#7 2017-05-06 13:06:07

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#8 2017-05-09 06:29:34

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#9 2017-05-09 07:13:52

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#10 2017-05-10 08:08:03

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#11 2017-05-15 00:09:34

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#12 2017-05-15 08:21:09

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#13 2017-05-19 07:21:11

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#14 2017-05-19 10:08:54

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#15 2017-05-21 16:49:40

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#16 2017-05-21 20:13:45

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#17 2017-05-21 20:47:01

Re: System fails to suspend, goes black screen and unresponsive sometimes.

#18 2017-06-13 15:13:20

Re: System fails to suspend, goes black screen and unresponsive sometimes.

Board footer