SOLVED System Won't Resume from Sleep/Suspend (Black Screen)

[qed]

I'm a new Linux user who is trying to move away from Windows 10. I recently began using Linux Mint, and really enjoy it, but when I wake up the computer from sleep/standby, the display/monitor does not show the desktop and only a black screen and a message of "no input received". I'm forced to do a hard restart or ctrl + alt + f3 to get back into terminal and restart from there.

My current system specs are:

Aorus Z390 Pro Wifi motherbord

Intel i5 9600K CPU

Nvidia RTX 2080 SUPER GPU (Using Nvidia drivers version 460.39)

Kernel version: 5.4.0-70-generic

Here is the full text of "inxi -Fxxxrz":

Code: Select all

System:
  Kernel: 5.4.0-70-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Cinnamon 4.8.6 wm: muffin 4.8.1 dm: LightDM 1.30.0 
  Distro: Linux Mint 20.1 Ulyssa base: Ubuntu 20.04 focal 
Machine:
  Type: Desktop System: Gigabyte product: Z390 AORUS PRO WIFI v: N/A 
  serial: <filter> 
  Mobo: Gigabyte model: Z390 AORUS PRO WIFI-CF v: x.x serial: <filter> 
  UEFI: American Megatrends v: F11 date: 10/15/2019 
CPU:
  Topology: 6-Core model: Intel Core i5-9600K bits: 64 type: MCP 
  arch: Kaby Lake rev: D L2 cache: 9216 KiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 44398 
  Speed: 800 MHz min/max: 800/4600 MHz Core speeds (MHz): 1: 800 2: 800 
  3: 800 4: 800 5: 800 6: 800 
Graphics:
  Device-1: NVIDIA TU104 [GeForce RTX 2080 SUPER] vendor: eVga.com. 
  driver: nvidia v: 460.39 bus ID: 02:00.0 chip ID: 10de:1e81 
  Display: x11 server: X.Org 1.20.9 driver: nvidia 
  unloaded: fbdev,modesetting,nouveau,vesa resolution: 2560x1440~100Hz 
  OpenGL: renderer: GeForce RTX 2080 SUPER/PCIe/SSE2 v: 4.6.0 NVIDIA 460.39 
  direct render: Yes 
Audio:
  Device-1: Intel Cannon Lake PCH cAVS vendor: Gigabyte 
  driver: snd_hda_intel v: kernel bus ID: 00:1f.3 chip ID: 8086:a348 
  Device-2: NVIDIA TU104 HD Audio vendor: eVga.com. driver: snd_hda_intel 
  v: kernel bus ID: 02:00.1 chip ID: 10de:10f8 
  Device-3: Microdia type: USB driver: snd-usb-audio,uvcvideo 
  bus ID: 1-13.4:9 chip ID: 0c45:6366 serial: <filter> 
  Sound Server: ALSA v: k5.4.0-70-generic 
Network:
  Device-1: Intel Wireless-AC 9560 [Jefferson Peak] driver: iwlwifi 
  v: kernel bus ID: 00:14.3 chip ID: 8086:a370 
  IF: wlo1 state: up mac: <filter> 
  Device-2: Intel Ethernet I219-V vendor: Gigabyte driver: e1000e v: 3.2.6-k 
  port: efa0 bus ID: 00:1f.6 chip ID: 8086:15bc 
  IF: eno2 state: down mac: <filter> 
Drives:
  Local Storage: total: 2.27 TiB used: 176.17 GiB (7.6%) 
  ID-1: /dev/nvme0n1 vendor: Crucial model: CT1000P1SSD8 size: 931.51 GiB 
  speed: 31.6 Gb/s lanes: 4 serial: <filter> rev: P3CR021 scheme: GPT 
  ID-2: /dev/sda vendor: Western Digital model: WDBNCE5000PNC 
  size: 465.76 GiB speed: 6.0 Gb/s serial: <filter> rev: 90WD scheme: GPT 
  ID-3: /dev/sdb type: USB vendor: Western Digital model: WD10JMVW-11AJGS1 
  size: 931.48 GiB rotation: 5400 rpm serial: <filter> rev: 1042 scheme: MBR 
Partition:
  ID-1: / size: 456.96 GiB used: 10.58 GiB (2.3%) fs: ext4 dev: /dev/sda2 
Sensors:
  System Temperatures: cpu: 52.0 C mobo: N/A gpu: nvidia temp: 56 C 
  Fan Speeds (RPM): N/A gpu: nvidia fan: 0% 
Repos:
  No active apt repos in: /etc/apt/sources.list 
  Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
  1: deb http://mirror.os6.org/linuxmint.com/packages ulyssa main upstream import backport
  2: deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse
  3: deb http://archive.ubuntu.com/ubuntu focal-updates main restricted universe multiverse
  4: deb http://archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
  5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
  6: deb http://archive.canonical.com/ubuntu/ focal partner
  Active apt repos in: /etc/apt/sources.list.d/papirus-papirus-focal.list 
  1: deb http://ppa.launchpad.net/papirus/papirus/ubuntu focal main
Info:
  Processes: 241 Uptime: 12m Memory: 15.57 GiB used: 1.91 GiB (12.3%) 
  Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Shell: bash 
  v: 5.0.17 running in: gnome-terminal inxi: 3.0.38

My system has two hard drives, one for Windows 10 and the other for Linux. I disabled Windows fast boot because that was causing major issues with the Wi-Fi in Linux.

I first began using Kubuntu and the same issue happened, so I switched to Linux Mint, thinking it would resolve the issue, but nothing has changed (I'm glad I switched from Kubuntu, I absolutely love Linux Mint).

Can anyone help? I'm so irritated because this issue is preventing me from completely switching over to Linux from Windows 10.

Thanks!

[deepakdeshp]

Install latest version of 5.8 series kernel from update manager.Reboot to it and test.

[SMG]

If updating the kernel does not help, you might want to consider updating your BIOS/UEFI. The latest version F12k on this page Z390 AORUS PRO WIFI (rev. 1.0) mentions changes which affect the GPU. Often GPU issues correspond to resuming from suspend issues.

If either of those does not work, then it will be time to start checking the logs to see what is happening.

[qed]

I updated my BIOS to the latest version, and set the kernel to the latest 5.8 series, but that did not resolve the issue. I'm beginning to believe I'm cursed. What else can I do?

[SMG]

After it freezes and you power down and then restart, run the following command in a terminal.
journalctl -rb -1 | nc termbin.com 9999
The command prints the journal log information of the prior boot cycle (the one which ended a freeze and you cutting power to the system) in reverse order (which hopefully puts the problem near the top) and sends it to termbin. It will return with a url address that you should post in your next reply.

[qed]

After it freezes and you power down and then restart, run the following command in a terminal.
journalctl -rb -1 | nc termbin.com 9999
The command prints the journal log information of the prior boot cycle (the one which ended a freeze and you cutting power to the system) in reverse order (which hopefully puts the problem near the top) and sends it to termbin. It will return with a url address that you should post in your next reply.

I typed that command in my terminal but it did not return a URL. It just returns me to a new root prompt. I seriously think Linux just hates me lol.

[SMG]

I typed that command in my terminal but it did not return a URL. It just returns me to a new root prompt. I seriously think Linux just hates me lol.

We'll get it to love you. Do not worry.

Maybe there was an internet glitch or something is wrong at termbin. Try running this:

Code: Select all

journalctl -b -1 | tee >(gzip --stdout > journalctl_$USER.gz)

This command will write that same log (but not in reverse order this time) to the file journalctl_(yourname).gz and to your screen. The file will be located in your /home/login_name directory. Hopefully, the zipped log will be small enough you can attach it to your next reply.

[qed]

Maybe there was an internet glitch or something is wrong at termbin. Try running this:

Code: Select all

journalctl -b -1 | tee >(gzip --stdout > journalctl_$USER.gz)

This command will write that same log (but not in reverse order this time) to the file journalctl_(yourname).gz and to your screen. The file will be located in your /home/login_name directory. Hopefully, the zipped log will be small enough you can attach it to your next reply.

Ok I've attached the requested document.

[SMG]

I updated my BIOS to the latest version, and set the kernel to the latest 5.8 series, but that did not resolve the issue.

The log you posted shows your system booting with the 5.4.0-70 kernel and using the F11 UEFI from October (not the latest).

When you power down the computer (not reboot it), it starts a new journalctl. I presumed when you said you were having the same issue that you have powered down at least once since after installing the 5.8 kernel and rebooting. You have to reboot for the 5.8 kernel to be installed and take effect.

So what I presumed happened was you installed the 5.8 kernel and rebooted. Then you suspended the computer. You tried to wake it and it did not wake so you powered it down and restarted it. Then you ran the log. That does not seem to be the case, so I may not have asked you for the correct information.

Please let us know what is wrong with my assumptions before I spend a lot of time looking at what is probably the wrong log.

[deepakdeshp]

Best is reboot ,

Code: Select all

uname -r

will give the running kernel. When it shows 5.8 attach the log once more.

[qed]

When I run

uname -r

in terminal, it's showing the 5.8.0 kernel. Here is the termbin link: https://termbin.com/auld

I shut down the computer and restarted it several times after installing the 5.8 kernel, so it should be good.

[deepakdeshp]

Copy paste the output of commands here in code tags. Install Latest version of 5.8 series , reboot and run uname -r

[qed]

Copy paste the output of commands here in code tags. Install Latest version of 5.8 series , reboot and run uname -r

What commands? I gave a link to the termbin, which came from the

journalctl -rb -1 | nc termbin.com 9999

command.

When I run uname -r it returns 5.8.0-48-generic. I've updated the kernel to the latest version.

[SMG]

Here is the termbin link: https://termbin.com/auld

This log does have the 5.8 kernel and the newer UEFI.

I do not see any messages which indicate what might be happening. All is going along and then the next thing I see is the Cinnamon logout message which I presume happens when you shut down the computer. Notice there is a time difference between the first two lines below and the subsequent two lines. I presume that is when the monitor went to sleep. Normally, when the computer goes to sleep there are lines in the log indicating that happens. There are none in this case, so this seems to be a monitor issue.

Code: Select all

Apr 05 18:57:49 nick-Z390-AORUS-PRO-WIFI rtkit-daemon[972]: Supervising 6 threads of 2 processes of 1 users.
Apr 05 18:57:49 nick-Z390-AORUS-PRO-WIFI rtkit-daemon[972]: Supervising 6 threads of 2 processes of 1 users.
Apr 05 19:06:58 nick-Z390-AORUS-PRO-WIFI polkitd(authority=local)[741]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.53, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
Apr 05 19:06:58 nick-Z390-AORUS-PRO-WIFI cinnamon-session[957]: WARNING: t+2967.04280s: Playing logout sound '/usr/share/mint-artwork/sounds/logout.ogg'

I recently began using Linux Mint, and really enjoy it, but when I wake up the computer from sleep/standby, the display/monitor does not show the desktop and only a black screen and a message of "no input received". I'm forced to do a hard restart or ctrl + alt + f3 to get back into terminal and restart from there.

There is a difference between the system being able to resume from sleep (the title of the thread) and the monitor losing its signal and not responding. Based on the lack of "sleep" messages in the log, I am presuming the connection between the Nvidia GPU and the monitor is the issue in this situation.

I would first completely disconnect both ends of your monitor cable and reconnect them to make sure this issue is not related to a slightly "off" physical connection.

Next I would check in the Power Management app to see what settings are there for turning off the screen.

Does your monitor have automatic shut-off functionality that might be the issue? Or DPMS functionality that might need tweaked?
Maybe you could try a different port on the GPU?
If none of that works, you could try a different Nvidia driver. If there is not a newer one available than what you have, I would suggest trying the Nvidia-450.

You may know monitor troubleshooting better than me, so feel free to comment on my suggestions.

[qed]

I don't believe the issue lies with my monitor. I'm duel booting Linux Mint alongside Windows 10, and I don't have the same issue on Windows 10. I do think you are correct in that the monitor/display is not receiving a single from the GPU when the computer "wakes up" from suspend mode. I think it's a motherboard issue, but I'm not sure. Perhaps the motherboard is using the integrated graphics that comes with my CPU (i5 9600K), although I'm not sure how that makes sense.

I've checked the power settings on Linux Mint and I've disabled suspend, but the computer still goes into suspend mode! When I deliberately tell the computer to suspend from the shut down menu, I still get the same problem. Seriously I think I'm cursed or something lol

[SMG]

I don't believe the issue lies with my monitor. I'm duel booting Linux Mint alongside Windows 10, and I don't have the same issue on Windows 10. I do think you are correct in that the monitor/display is not receiving a single from the GPU when the computer "wakes up" from suspend mode.

What do you think is suspending? There were no log messages which indicate the computer was suspended.

There is a setting in Power Management for the screen to blank, but that is not the same as suspending. Your monitor may be set to power-save which is turning off the display.

I think it's a motherboard issue, but I'm not sure. Perhaps the motherboard is using the integrated graphics that comes with my CPU (i5 9600K), although I'm not sure how that makes sense.

The graphics information indicates only the nvidia driver is loaded and running. Mint has not loaded any drivers for the integrated graphics.
Graphics:
Device-1: NVIDIA TU104 [GeForce RTX 2080 SUPER] vendor: eVga.com.
driver: nvidia v: 460.39 bus ID: 02:00.0 chip ID: 10de:1e81
Display: x11 server: X.Org 1.20.9 driver: nvidia
unloaded: fbdev,modesetting,nouveau,vesa resolution: 2560x1440~100Hz
OpenGL: renderer: GeForce RTX 2080 SUPER/PCIe/SSE2 v: 4.6.0 NVIDIA 460.39
direct render: Yes

I've checked the power settings on Linux Mint and I've disabled suspend, but the computer still goes into suspend mode!

Please realize there is a difference between the screen blanking and the computer suspending. Why do you think your computer is suspending? Notice that I have not asked you about your screen blanking because than can be and probably is a separate issue from your computer suspending.

[qed]

SMG,

Thanks for your continued support on this issue.

I believe the computer is going into suspend mode because when I deliberately tell it to suspend (via the shut down menu options), it does the same thing. I do have the screen to turn off after 30 minutes, as I wanted the screen to turn off, but nothing else. When I try to wake the computer up from (what I believe to be), the suspend mode, the monitor says "no signal received". So essentially there is no signal coming from the GPU, but when I press alt+ctrl+f1, I get a terminal and have to restart/shutdown the computer from there.

[SMG]

When I try to wake the computer up from (what I believe to be), the suspend mode, the monitor says "no signal received".

After doing your normal "wake up" step, try doing Ctl-Alt-Backspace. That will restart the X Server which controls the graphics. Maybe that will have the GPU re-poll the monitor ports and wake up the connection between the monitor and the GPU.

What type of connection (HDMI, DP) is it? Have you tried the Nvidia-450 driver yet?

When other people have had issues with computers not resuming from suspend, they were not able to get tty connection. That is why I think this is more of a monitor related issue.

[qed]

Oddly enough, for reasons I can't quite explain, the issue I had is now resolved. Why or how this happened, I've no idea. When I place the computer into suspend mode from the shutdown menu, I'm able to wake it back up. I have the power settings set so that the monitor turns off after 30 min, and I haven't waited taht long from the point where I set the computer to suspend, and when I wake it up, so perhaps that needs to be tested as well.

I do sometimes lose keyboard functionality when I wake the computer back up for whatever reason.

Sometimes I believe I was cursed, and now the curse is lifted. Regardless, thanks for your help!

[SMG]

There were multiple updates which came through today, so maybe they were a factor.

Hopefully, all will be well going forward.