RTX 4080 / nvidia-open 615.78.08: black screens after suspend

seth · 2026-11-07 21:23:13

So the GUI never returns on the nvidia outputs but they still show console messages and a (new) getty?
Same w/ startx/X11 (no plasma-login-manager or other kwin_wayland instances)?
Does the nvidia GPU still respond to nvidia-smi (no matter on which output)?

Maybe VRR related?

for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; done

You'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/

Lukasas · 2026-11-07 22:58:26

So, few new observations

I installed a fresh Arch Linux, with GNOME environment. I tried systemctl suspend and it got stuck so not even the iGPU worked.
When I rebooted and set this

PreserveVideoMemoryAllocations: 0
UseKernelSuspendNotifiers: 0
TemporaryFilePath: "/var/tmp"

rebooted and tried to suspend, suddenly the iGPU worked.
I then tried to going to openbox with x11, so that I set it, logged out of the gnome environment, switched to another VT and ran the startx.

In there, I opened xterm and typed systemctl suspend.
Then woke up the PC, it did, I saw only blackscreen with a cursor, like when I first started the openbox, but I could not open the right click menu, or I think I could not see that.
When I mouse-over the place, where I had the terminal, I saw the cursor change to like the caret for typing and when I located the terminal edge I saw the resize cursor.
I switched to another VT, tried

systemctl restart graphical.target

that did not help, but when I tried to switch to the VT where the GNOME login was, it showed up but frozen.
It was like not fully showed up, meaning the text, buttons etc.. were faded.
When I switched to VT console it was stuck but after awhile it got unstuck and I saw messages

[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 0
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Flip event timeout on head 1

Then I switched back to the GNOME login and it was like loaded - not faded anymore, but still frozen. I switched back to terminal, again the Flip event timeout on head.. popped up.
I tried nvidia-smi that was giving output and showing the GPU working with temps.

this is the output of the edid-decode on the plasma desktop (before any suspend]

https://termbin.com/n6zr

and this is after the suspend, waking up to black screens of GPU and working screen of iGPU

nvidia-smi
https://termbin.com/a0obk

edid-decode
https://termbin.com/0e3p

Now when I was switching the Ctrl + Alt + F1 F2 F3 it got stuck for a moment showing the Flip event timeout on head 0, so I tried switching again it got stuck that I couldn't switch anymore and had to do reboot.
This is the journal of that
https://termbin.com/4fve

Last edited by Lukasas (2026-11-07 23:10:30)

seth · 2026-11-08 14:42:56

Then woke up the PC, it did, I saw only blackscreen with a cursor

Was the output attached to the GPU or the APU? Was this only openbox or openbox + picom?

when I tried to switch to the VT where the GNOME login was

The idea was to simplify the setup as much as possible - only the console or only a plain uncomposited X11 server - not other display servers on parallel VTs.

/sys/class/drm/card2-DP-4
Manufacturer: AOC
    Model: 1
    Made in: week 8 of 2016
Display supports continuous frequencies

/sys/class/drm/card2-DP-5
Manufacturer: AOC
    Model: 42513
    Made in: week 45 of 2025
Display supports continuous frequencies

in contrast to

/sys/class/drm/card1-HDMI-A-1
    Manufacturer: AUS
    Model: 9988

=> Can you disable VRR (G-Sync or FreeSync) in the monitors OSD settings?

Lukasas · 2026-11-08 15:26:47

I did another try. Disabled VRR (G-Sync] in the monitors OSD.
Booted to the console VT with GNOME and wayland disabled - checked it with htop so there are no processes with gnome or wayland.

So I started openbox with startx, suspended, woke it up and the iGPU showed no input but the GPU monitor was showing only mouse cursor without the terminal I opened for the systemctl suspend.
Again I was able to locate, where the terminal is by the changing cursor, clicked in and tried systemctl reboot and it rebooted.

https://termbin.com/5s0h

seth · 2026-11-08 22:30:48

Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
There're no indications for nvidia, amdgpu or drm related problem in the latest journal, but black screen + mouse cursor sounds like there's either a compositor (and invalid textures) or reverse prime (rendered on AMD, copied via the nvidia GPU for output) but

Nov 08 15:10:11 archlinux kernel: fbcon: nvidia-drmdrmfb (fb0) is primary device

and the AMD monitor not producing any signal contradicts the latter.
Also remove

PreserveVideoMemoryAllocations: 0
UseKernelSuspendNotifiers: 0
TemporaryFilePath: "/var/tmp"

for now - VRAM preservation certainly didn't take place so let's see whether and what changes that introduces.

Lukasas · Yesterday 16:02:03

Alright, so I started the openbox, did the suspend and wake, the console, where I typed systemctl suspend again not showing, then typed systemctl reboot and the xterm console flashed on a second before the system rebooted
this is the Xorg log for that session:

https://termbin.com/6jh4

Lukasas · Yesterday 16:41:05

Alright, I think I isolated the problem.

I did all the tries on the openbox and then returned to my main OS, removed the Preserve...=0 too and tried suspending.
Suspended, tried to wake it up - it woke up.
Tried again - woke up.
again - woke up...

The only weird thing is, that one of the monitors is always like with small resolution, but only after the first suspend. When I leave it and suspend again, it wakes up completely fine and its fine for each next waking.
I had everything except mouse and keyboard disconnected.
So I connected everything and again, it was completely fine.
I turned the G-Sync back, tried like 5 suspends - everything woke up fine.
So I disconected the HDMI monitor and plugged DP into it, tried to suspend and it did NOT wake up.
Black screens no cursor nothing, unplugged the DP, plugged HDMI still black.

This is journal when it hanged
https://termbin.com/j20hj

this is Xorg log
https://termbin.com/i4gq

//edit:

So its when that specific monitor is plugged in.
I tried different DP cable, different DP output on GPU still black screen.

//edit2:

I have all the variable frequencies on that specific monitor turned off and now I tried it on the 59.95 Hz (what is reporting OS as the lowest possible refresh rate)
and even with that when that monitor is plugged in DP the system does not wake up.

Weird thing is, that this monitor is not like old monitor. Its ASUS TUF Gaming VG27AQL1A and it has no problem waking up on Windows.

I tried plugging in the monitor into GPUs HDMI and its working fine. I set the monitors frequencies to values I have on DP and still working just fine.
Next I tried to reorganize the monitors and set their desktop priorities and it still wakes up fine.
So only when that monitor is plugged in the DP, it does not wake up.
It can't be bad port on the GPU, because it does not matter which DP I plug the monitor into.

Are there any options, how to figure out, what exactly is wrong? Could it be that the nvidia driver can't wake with this specific monitor?

Last edited by Lukasas (Yesterday 17:54:23)

seth · Yesterday 20:57:01

So its when that specific monitor is plugged in.
I tried different DP cable, different DP output on GPU still black screen.

The ASUS VG27AQL1A ? And it's irrelevant whether it's connected to the GPU or the APU?
Edit: missed your 2nd edit - hold on

Can you check "xrandr -q" when failing to wake up from an X11 session?
You can "DISPLAY=:0 xrandr -q | tee /tmp/xrandr.out" to query the information from the console.

Edit #2: also when connecting it to the GPUs HDMI and it works.

The weird situation w/ the black screen + mouse cursor is gone after re-enabling VRAM preservation?

Last edited by seth (Yesterday 21:00:47)

Lukasas · Yesterday 21:29:13

So, when that monitor is plugged into a DisplayPort it won't like show anything anymore.

I tried this on both systems, the openbox and my main and both behave the same.
I suspend the PC, wake it up, the other two monitors light up, like their LED light like they got source from the GPU but stay black and that one monitor says DisplayPort no signal.
I tried connecting one of the two working monitors into the iGPU HDMI but that did nothing. Even when I rebooted it in that setup, suspended... still the same result.
As long as that one monitor is plugged into the DisplayPort, it wont like show any display.

I tried going "blind" like pressing the Ctrl + Alt + F3, logging in and typing systemctl reboot, but that did nothing.

I tried bringing back the VRAM preservation and the result is the same.
Is there like a SysRq that could log something? Or a script that runs upon waking up?

//edit:

Alright, So after few tries, I managed to get it where the iGPU is working. It was like 3 tries and now the GPU output is black.
this is now the output of the command:

https://termbin.com/2zr2u

//edit2:

So I did few more tests.
I tried connecting only that one monitor. It behaves the same. Even when that one monitor is the only thing connected to the GPU it wont wake.
I noticed, that few times it does wake. Like I suspend it, try to wake it, it wakes fine but the second suspend wont wake.
Its not like its always on the second suspend, almost all of the time its the first suspend.

Last edited by Lukasas (Yesterday 21:56:46)

seth · Today 20:22:51

I managed to get it where the iGPU is working. It was like 3 tries and now the GPU output is black

The randr output shows all three monitors enabled at their default modes 1080p60 (HDMI), 2160p144 (DP-5) and 1440p120 (DP-6)

For clarification/simplification: as long as the monitor isn't connected at all, the remaining two work reliably fine?
Connecting the troublesome output via display port (to the GPU) breaks everything, connecting it to the APU (or GPU?) via HDMI is never a problem?

Does the nvidia GPU actually have three displayport outputs or are you using a hybrid USB/DP port or do you daisy-chain the monitors?

Lukasas · Today 20:55:54

Yes, as long as the one "problematic" monitor is not connected to GPU DisplayPort, the two work reliably fine. I tried Only those two, suspending and waking up and everything was fine.
I then disconnected one of the fine monitor and connected that cable to that problematic one, so I would eliminate bad port on GPU or cable. But even in different DP output - when the monitor was connected it did not wake up.
It was like it was not receiving any signal.
BUT
when I connect that specific monitor into GPU HDMI, it work just fine. I now have two in DisplayPort and that one in HDMI.
The GPU have three DisplayPorts and one HDMI (so 4 outputs)

seth · Today 20:58:57

Does the monitor provide different EDIDs when connected to the DP and HDMI outputs?

Edit: resp. are there any subjective downsides to running it on HDMI?

Last edited by seth (Today 21:01:01)

Lukasas · Today 21:15:03

Well, the G-Sync is unavailable on the HDMI and I think it tops at 120 Hz that's all. But non of that is a problem for me, its my secondary monitor so I'm fine with that.

This is connected with HDMI
https://termbin.com/zt2kr

and this is with DP
https://termbin.com/517vk

seth · Today 21:23:23

Well, the G-Sync is unavailable on the HDMI and I think it tops at 120 Hz that's all.

The EDID still advertises

DTD 2:  2560x1440  144.006152 Hz  16:9    222.201 kHz    595.500000 MHz (597 mm x 336 mm)
                 Hfront    8 Hsync  32 Hback   80 Hpol P
                 Vfront   25 Vsync   8 Vback   70 Vpol N

but not VRR and most likely that (advertised on DP) also the cause of your problems - does the monitor advertise G-Sync (ie. the marketing certification from nvidia)?

Lukasas · Today 21:30:48

Yes, the monitor advertise G-Sync.

The exact model is on the nVidia G-Sync list

https://www.nvidia.com/en-eu/geforce/pr … ors/specs/

But I also have another G-Sync monitor, that is working just fine - my main monitor.

Arch Linux

#26 2026-11-07 21:23:13

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#27 2026-11-07 22:58:26

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#28 2026-11-08 14:42:56

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#29 2026-11-08 15:26:47

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#30 2026-11-08 22:30:48

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#31 Yesterday 16:02:03

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#32 Yesterday 16:41:05

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#33 Yesterday 20:57:01

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#34 Yesterday 21:29:13

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#35 Today 20:22:51

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#36 Today 20:55:54

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#37 Today 20:58:57

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#38 Today 21:15:03

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#39 Today 21:23:23

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

#40 Today 21:30:48

Re: RTX 4080 / nvidia-open 615.78.08: black screens after suspend

Board footer