Similar issue here on Fedora 44. If I boot the system with two monitors, after login the system freezes. If I disconnect the second monitor and reboot it works fine! It also works if I connect the second monitor after booting with only one. The previous NVIDIA drivers had no problem, happened immeddiately after upgrading to 620.
I can confirm it is still happening, and just happened to me. Manjaro Linux Testing, KDE Plasma 6.8 on Wayland, 620 drivers, 7.3.3 kernel. One hdmi monitor, one displayport monitor, both running at 1920*1080@60hz
Attached are the output of
$ journalctl --user-unit plasma-kwin_wayland --boot 1 > plasma-kwin_wayland.log
$ journalctl -k -b -1 > dmesg.log
as requested by said logs
dmesg.log (138.5 KB)
plasma-kwin_wayland.log (73.2 KB)
This driver is still having issues with killing the DP connection, details below with the help of Claude.
Title: [620.70.06 open, RTX 4090] DP-2 (ASUS PG32UCDM) never recovers after
monitor KVM/input switch away and back; Flip event timeout, EDID read failure
SUMMARY
After the monitor’s input is switched to USB-C (Windows 11 laptop) for a while
and then back to DisplayPort, the DP link is completely dead. No signal until I
toggle the monitor’s OSD power-save mode, which gives me a TTY, then
“systemctl restart display-manager”. This regressed with 615 and is still
present in 620.70.06.
SYSTEM
GPU: NVIDIA GeForce RTX 4090
Driver: 620.70.06, nvidia-open-dkms 620.70.06-2 (built locally via DKMS)
Kernel: 7.3.3-1-cachyos (CachyOS)
Session: Wayland, [KDE Plasma version]
Monitor: ASUS PG32UCDM on DP-2, built-in USB KVM, [4K/240HZ, HDR, VRR, DSC]
Cable: Silkland 1.5m DP80 certified
Kernel cmdline:
initrd=\initramfs-linux-cachyos.img rw zswap.enabled=0 nowatchdog quiet splash vi
deo=DP-2:e
STEPS TO REPRODUCE
- Use the monitor on the DP input from the Linux PC.
- Switch the monitor (and KVM) to the USB-C input for a Windows 11 laptop.
- After [10 minutes or so], switch back to DP.
Result: no signal. [Reproducible every time]
EXPECTED
Link retrains and the display returns on its own.
KERNEL LOGS (attached)
Flip event timeout on head 0
Flip event timeout on head 1 (3 s later)
WARNING: nvidia-drm/nvidia-drm-crtc.h:371 at __nv_drm_handle_flip_event
(call path: nvKmsKapiHandleEventQueueChange → nv_drm_event_callback)
nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device
Asustek Computer Inc PG32UCDM (DP-2)
WORKAROUND
OSD power-save toggle → TTY → restart display-manager.
video=DP-2:e,
RELATED
Flip event timeout also reported on the 620 thread
615 regression thread: 615 release feedback & discussion
Attached: nvidia-bug-report.log.gz , journal excerpt.
flip-timeout.log (9.1 KB)
nvidia-bug-report.log.gz (938.1 KB)
edid-failure.log (16.5 KB)
Hardware spec:
- Acer Aspire 7 Laptop
- CPU: AMD 5625U
- GPU: RTX 3050 Laptop GPU
- RAM: 32GB - Usable 29.7GB
- Display configuration: Using laptop screen
- Monitor Chimei Innolux Corporation 0x1521 1920x1080@144.00Hz
System info:
- Linux CachyOS rolling release with 7.3.3 linux-cachyos kernel
- NVIDIA driver 620.70.06-1
- Desktop Environment: Hyprland 0.57 / GNOME 51
Games affected:
- Neverness To Everness - Game black screen and Nvidia GPU crash immediately upon trigger ingame cutscene with the Out-of-memory error inside Linux log
- Honkai: Star Rail
Issue info:
-
Driver regression: YES - The games work perfectly fine with previous Nvidia driver. Last I can remember is 617
-
Expected behavior:
- Nvidia driver tell GPU to unload old asset datas and load new ones + Game framerate drop for one or two seconds and the game continues as normal
-
Actual behavior:
- Nvidia GPU crash the moment new assets needed to load - usually right at the moment cutscene trigger, causing abnormally high CPU utilization - In some observed cases, it can spike up to 150% - causing entire system to become completely paralyzed.
- Affected processes, including game processes, proton compatible layer related processes to be unkillable even with Super User permission.
- Nvidia-smi become paralyzed, unable to start or just immediately freeze the terminal that it is running on
-
Reproduce steps:
- A full system wipe + Reinstall system using CachyOS live ISO installer
- Install proton-cachyos-slr, proton-cachyos-native, lutris and all of those dependencies
- Launch Neverness To Everness using Lutris with following options:
- disable_runtime: true
- env:
- DXVK_HDR: ‘1’
- DXVK_HUD: ‘1’
- DXVK_NVAPI_DRS_NGX_DLSS_FG_OVERRIDE: ‘on’
- DXVK_NVAPI_DRS_NGX_DLSS_FG_OVERRIDE_RENDER_PRESET_SELECTION: render_preset_k
- DXVK_NVAPI_DRS_NGX_DLSS_RR_OVERRIDE: ‘on’
- DXVK_NVAPI_DRS_NGX_DLSS_RR_OVERRIDE_RENDER_PRESET_SELECTION: render_preset_k
- DXVK_NVAPI_DRS_NGX_DLSS_SR_OVERRIDE: ‘on’
- DXVK_NVAPI_DRS_NGX_DLSS_SR_OVERRIDE_RENDER_PRESET_SELECTION: render_preset_k
- DXVK_NVAPI_VKREFLEX: ‘1’
- GAMEID: umu-nte
- MANGOHUD: ‘1’
- OBS_VKCAPTURE: ‘1’
- PROTON_DLSS_INDICATOR: ‘1’
- PROTON_ENABLE_NGX_UPDATER: ‘1’
- PROTON_ENABLE_NVAPI: ‘1’ PROTON_ENABLE_WAYLAND: ‘1’
- PROTON_LOCAL_SHADER_CACHE: ‘1’
- PROTON_LOG: ‘1’
- PROTON_NO_WM_DECORATION: ‘0’
- PROTON_VERB: waitforexitandrun
- SteamDeck: ‘1’
- SteamOS: ‘1’
- __GL_SHADER_DISK_CACHE_SIZE: ‘5000000000’
- __GL_SHADER_DISK_CACHE_SKIP_CLEANUP: ‘1’
- game_path: /Storage/Games/NSteam/Prefixes
- gamemode: false
- gpu: card2
- prefix_command: game-performance
- wine:
- fsr: false
- version: system
- After a few minutes of moving around, the game hard lock up and the CPU utilization started to climb continously.
Logs and extra infos:
- The issue remains even with a clean game setup - meaning all PROTON environment variables removed.
- PROTON-CACHYOS-SLR Log: https://drive.google.com/file/d/1x3HPOPx2m7C-qAZTO5JLeaZgnJ2Wzj7U/view?usp=drive_link
Edit: Did not know this forum support attachment.
Edit 2: Including PROTON log in case it help
nvidia-bug-report.log.gz (513.4 KB)
cachyos-bugreport.log (187.6 KB)
Same behavior here on Arch Linux with 620.70.06.
Setup:
- GPU: GeForce RTX 3060 12GB
- Driver: nvidia-open-dkms 620.70.06-1, plus nvidia-utils, nvidia-settings and lib32-nvidia-utils at 620.70.06-1
- Kernel: 7.3.4-zen2-2-zen (linux-zen)
- Desktop: KDE Plasma 6.8.2, Frameworks 6.31.0, Qt 6.12.0, Wayland session
- CPU / board: Ryzen 7 9700X, Gigabyte X870 AORUS ELITE WIFI7
- Monitors: two, both connected via DisplayPort
Symptom:
With both monitors connected at boot, the desktop is almost unusable. The screen only redraws when an input event happens (for example, pressing Super opens the launcher and the screen updates at that moment), and the mouse cursor moves in jerks.
What I verified:
- Disconnecting the DisplayPort cable of one monitor before boot: the system starts and works normally on 620.70.06.
- Connecting the second monitor after login: both monitors and the system work fine.
- Downgrading to 615.78.08: works normally with both monitors connected, same configuration otherwise.
Yes, also after reconnecting the second monitor, if you logout and log back in the same behavior, freeze!
4K 120 Hz HDR over HDMI 2.1 flickers on 620.70.06 with an LG TV, fine on 615.78.08. Details and nvidia-bug-report log here: 620.70.06: 4K 120 Hz HDR over HDMI 2.1 flickers every few seconds on LG TV, fine on 615.78.08
Same issue as #42 and #46 (two monitors at boot, KDE Plasma Wayland), here on an RTX 5080. My kernel log additionally shows atomic modeset failures (-22) and the display engine failing to idle. Had to roll back to 615.78.08.
System
- GPU: RTX 5080, open kernel modules (Arch nvidia-open-dkms)
- CPU: Ryzen 9 9950X3D, iGPU enabled (amdgpu loaded, no displays attached)
- Board: MSI X870E Carbon, BIOS 7E49v1AA7
- Displays: 2x 2560x1440 @ 180 Hz over DisplayPort
- Arch Linux, KDE Plasma 6.8 Wayland
- Kernels: 7.3.4-arch1-1 and 6.18.63-2-lts, same behavior on both
- Params: nvidia_drm.modeset=1 nvidia_drm.fbdev=1 nvidia.NVreg_PreserveVideoMemoryAllocations=1 pci=realloc
Kernel log (620.70.06)
[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000100] Failed to apply atomic modeset. Error code: -22
[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
nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000ca7e:4:0:1209
(repeats every ~2 s)
Full nvidia/drm kernel log attached. 615.78.08 on the same kernels works fine.
nvidia-620-flip-timeout.txt (20.3 KB)
I’m using Arch Linux, kernel 7.3.4.arch-1 and nvidia 620.70.06-2 play Phantom Blade Zero, when enter pang city, seem like vRAM can’t allocated, there are some log.
nvidia-bug-report.log.gz (2.0 MB)
With this update Cyberpunk 2077 crashes, when I play this game with Ray Tracing.
nvidia-bug-report.log (2.2 MB)
On this driver, I am still having issues using DSC, on my RTX4080, on Arch.
3840x2160
10-bit HDR
240Hz Refresh Rate
If I enable VRR, fullscreen applications still require a renegotiation when ALT+TAB, resulting in a temporary black screen.
Same problem on Manjaro, Kernel 7.3.3, Plasma 6.8.2, Two identical Dell monitors U2717D at DP. When I switch to IceWM Desktop Manager everything works fine!
I’ve had the same issue, please give this a try and if it solves anything, lemme know
NVIDIA 620.70.06 — RTX 2070 VirtualLink USB-C monitor causes KDE Wayland session loss; direct DisplayPort stable
System configuration
-
Operating system: Fedora 44 KDE
-
Desktop environment: KDE Plasma 6.8.2
-
Display protocol: Wayland (KWin)
-
Linux kernel: 7.3.3-200.fc44.x86_64
-
GPU: NVIDIA GeForce RTX 2070 (Turing architecture)
-
NVIDIA driver: 620.70.06
-
NVIDIA kernel module: Open GPU Kernel Modules
-
Kernel module license:
Dual MIT/GPL, confirmed using:modinfo -F license nvidia -
Monitors: Two Dell UltraSharp U2723QE 27-inch 4K displays
Problem description
I have experienced repeated unexpected KDE Wayland graphical-session logouts when operating two 4K monitors with the following connections:
-
Monitor 1: HDMI directly to the RTX 2070
-
Monitor 2: USB-C/VirtualLink directly to the RTX 2070
During these failures, the graphical desktop session becomes unavailable, requiring me to log in again or reboot to recover.
The NVIDIA kernel log contains repeated warnings:
nvidia-modeset: GPU:0: nvHandleCpEventDeferredWork: Cannot find pDpyEvo for displayId: 0x8000
nvidia-modeset: WARNING: GPU:0: nvHandleCpEventDeferredWork: displayId 0x8000 invalid
Additional journal entries show DRM hotplug events, display disconnections, and KDE applications failing to connect to the Wayland display.
For example, on November 12, 2026, the journal recorded USB device disconnections at approximately 15:27:41, followed by NVIDIA display-ID warnings and KDE display hotplug notifications.
Important qualification: I may have manually disconnected the USB-C cable during recovery. Therefore, the USB disconnection messages should not be interpreted as proof that the hardware spontaneously disconnected.
The logs establish a correlation between the problematic display configuration and graphical-session instability, but do not yet identify the initiating event.
Successful workaround and stability test
I changed only the second monitor’s connection:
Original configuration (unstable):
-
Dell U2723QE #1: HDMI
-
Dell U2723QE #2: RTX 2070 USB-C/VirtualLink
Current configuration (stable):
-
Dell U2723QE #1: HDMI
-
Dell U2723QE #2: Direct DisplayPort
Both monitors are operating as an extended 3840 × 2160 KDE Wayland desktop.
Result: 48 consecutive hours of completely stable operation with HDMI + DisplayPort.
The computer was also stable when operating with only the HDMI-connected monitor.
No NVIDIA driver downgrade, kernel change, or KDE configuration change was required to obtain this stability.
Possible related NVIDIA issue
The warnings resemble those discussed in:
NVIDIA/open-gpu-kernel-modules issue #1380
Other NVIDIA 615/620-series reports describe display hotplug instability and multi-monitor problems.
However, I have not established that those reports share the same root cause as my RTX 2070 VirtualLink USB-C issue.
Questions for NVIDIA developers
-
Is there a known regression in NVIDIA driver 620.70.06 involving RTX 2070 VirtualLink USB-C display output?
-
Is the
nvHandleCpEventDeferredWork/displayId 0x8000 invalidwarning associated with display hotplug handling or an invalid display object? -
Are there known differences in VirtualLink USB-C behavior between NVIDIA’s open and proprietary kernel modules?
-
Could a USB-C display hotplug or link failure cause KWin Wayland to terminate the graphical session?
-
Is there an existing patch or planned driver fix for this behavior?
I can provide journal excerpts, kernel messages, and an NVIDIA diagnostic report if requested.
The HDMI + DisplayPort configuration is currently stable, so I would prefer to avoid intentionally reproducing the failure unless additional diagnostics are specifically requested.