Repository navigation
615.71.09 regression: DisplayPort monitor power cycling hangs KWin in GSP RPC wait; nvidia-modeset blocked, shutdown hangs (RTX 4070) #1392
Description
NVIDIA Open GPU Kernel Modules Version
615.71.09 — regression compared with 610.57.04.
Proprietary kernel module comparison
Not tested with the proprietary kernel module of the same version. The affected boots explicitly loaded the NVIDIA Open Kernel Module.
Operating System and Version
Arch Linux, KDE Plasma / KWin Wayland.
Kernel Release
7.2.6-arch2-1, stable Arch Linux kernel. The same kernel is running after downgrading to 610.57.04.
Hardware: GPU
NVIDIA GeForce RTX 4070.
Monitor configuration and USB topology
- Main monitor: ASUS ROG Swift OLED PG27AQDP, identified as
PG27AQDPin its EDID. - Connector: DisplayPort,
card1-DP-2in DRM/sysfs,DP-2in KScreen. PowerDevil/ddcutil recordedDDCA_EVENT_DISPLAY_DISCONNECTEDforcard1-DP-2at 07:35:43 in affected boot96e603de58ef43ea93a3de2ce471f069, with/dev/i2c-4andddc working: false. - Main display mode during reproduction: 2560 × 1440 at 480 Hz, confirmed by the reporter as the mode used during the hangs on 615.71.09. After the downgrade, KScreen also reports 2560 × 1440 at 479.99 Hz (nominal 480 Hz). The current scale is 1.25, HDR is disabled and VRR policy is Never; these additional settings were measured after the downgrade and have not been confirmed for the affected boots.
- DSC: not directly confirmed by an active-link/DSC status capture. At 2560 × 1440 / 480 Hz, full RGB 8-bpc active pixels alone require approximately 42.47 Gbit/s, exceeding the 25.92 Gbit/s payload of four-lane DP HBR3. Thus DSC is expected for full RGB operation at this mode on the RTX 4070's DP link, but the exact negotiated color format, bit depth, DSC state and compression parameters during the failed modeset were not captured. No controlled DSC-on/off comparison has been performed. This is relevant to PR Allow DisplayPort detach bookkeeping when the sink is unplugged #1359, but does not establish the same root cause.
- Second monitor: ASUS ROG PG258Q, EDID name
ROG PG258Q, oncard1-DP-1/DP-1. Currently connected but disabled in KScreen; its listed selected mode is 1920 × 1080 / 60 Hz and it advertises up to 240 Hz. Its precise active state during each affected reproduction has not been independently established. - USB topology: the keyboard and mouse are connected through the monitor's USB hub, as confirmed by the reporter. The journal shows an ASUS USB hub (
0b05:1ba6, path1-5), a downstream GenesysLogic hub (05e3:0610, path1-5.2), an ASUS ROG Claymore keyboard (1-5.2.3) and a Razer DeathAdder V2 mouse (1-5.2.4). These devices re-enumerate at 07:41:15–07:41:17 and disconnect at 07:41:30 in the affected boot. Consequently, monitor power cycling can also interrupt local USB input; loss of keyboard/mouse input alone should not be taken as evidence of a whole-system kernel hang. SSH remained usable, while the GPU/modeset hang is independently documented by the kernel stacks.
Describe the bug
With 615.71.09, physically turning the main monitor off and back on causes the graphical session to hang. In my reproduction, the second off/on cycle leaves the screens black.
The machine remains accessible over SSH. Attempting to restart SDDM does not recover the graphical session, and a normal reboot does not finish shutting down.
Downgrading to 610.57.04 resolves the reported reproduction.
Journal evidence
Multiple affected boots were recorded on September 24, 2026. Times below are as displayed by journalctl.
One affected boot contains:
07:14:33 nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
07:16:24 INFO: task nvidia-modeset/:795 blocked for more than 122 seconds.
07:16:24 INFO: task nvidia-modeset/:795 blocked on a semaphore likely last held by task kwin_wayland:1010
In another affected boot, journal boot ID 96e603de58ef43ea93a3de2ce471f069, the hung-task reports recur:
07:38:16 INFO: task nvidia-modeset/:791 blocked for more than 122 seconds.
07:38:16 INFO: task nvidia-modeset/:791 blocked on a semaphore likely last held by task kwin_wayland:1001
07:40:19 INFO: task nvidia-modeset/:791 blocked for more than 245 seconds.
07:40:19 INFO: task InputThread:957 blocked for more than 122 seconds.
07:40:19 INFO: task nvhttp::47984:1694 blocked for more than 122 seconds.
KWin is reported as a running task (state:R). Its captured kernel stack includes the following functions, shown here as a summarized call path with DisplayPort C++ names demangled (not a verbatim backtrace):
drm_mode_atomic_ioctl
-> drm_atomic_commit
-> nv_drm_atomic_commit
-> nv_drm_atomic_apply_modeset_config
-> ApplyModeSetConfig
-> nvkms_ioctl_from_kapi_try_pmlock
-> nvKmsIoctl
-> nvSetDispModeEvo
-> nvDPPreSetMode
-> DisplayPort::ConnectorImpl::trainLinkOptimized
-> DisplayPort::EvoMainLink::train
-> DisplayPort::LinkConfiguration::lowerConfig
-> nvRmApiControl
-> rpcRmApiControl_GSP
-> _issueRpcAndWait
-> kgspRecvPoll_IMPL
The stack also contains _kgspRpcDrainEvents and kgspHealthCheck_TU102.
This suggests a stalled DisplayPort modeset involving a GSP RPC wait. The traces alone do not establish the underlying firmware/driver defect or prove that the GSP firmware crashed.
The SDDM stop attempt in that boot also times out:
07:37:32 Stopping Simple Desktop Display Manager...
07:38:32 QProcess: Destroyed while process ("/usr/bin/X") is still running.
07:39:02 sddm.service: State 'stop-sigterm' timed out. Killing.
07:39:02 sddm.service: Failed with result 'timeout'.
To Reproduce
- Boot with NVIDIA open kernel modules and driver 615.71.09.
- Start a KDE Plasma Wayland session with the main ASUS PG27AQDP connected over DisplayPort (
DP-2) at 2560 × 1440 / 480 Hz. A second monitor is connected as described above. - Physically turn the main monitor off, then back on.
- Repeat the off/on cycle.
- In my reproduction, the second cycle leaves the screens black.
- Connect over SSH: the system is still reachable, but restarting SDDM does not recover the desktop and normal reboot hangs.
Expected behavior
The display configuration should recover after each monitor power cycle, and the desktop should remain usable.
Bug Incidence
Repeated across multiple boots. The reported reproduction fails on the second monitor power cycle; the journal records the resulting hangs but does not independently establish the number of power cycles.
nvidia-bug-report.log.gz
Not collected during the affected state. The system has already been downgraded to 610.57.04. Persistent journal logs containing the affected kernel stacks are still available.
Related reports
- 615.71.09: display deadlock on DPMS wake — KWin modeset holds nvkms pmlock while blocked on RM API lock in DisplayPort getLinkConfig (Flip event timeout) #1371: similar nvidia-modeset semaphore wait behind KWin, black displays, and monitor-power-cycle/shutdown-hang reports. The initial report's KWin stack differs from mine.
- 615.71.09: hangs and vertical line corruption on DP monitors (RTX 4060), 610.57.04 works #1367: same driver regression and "Lost display notification"; a comment describes a similar DisplayPort/GSP wait.
- PR Allow DisplayPort detach bookkeeping when the sink is unplugged #1359: related DisplayPort power-cycle regression. I have not tested this patch and cannot confirm it fixes this hang.
Please advise whether this should be tracked under #1371 and which additional diagnostics would help distinguish the underlying issue.
Activity
Lubix89 commentedon Sep 25, 2026
Follow-up: September 25 comparison with 615.71.09 vs 610.57.04
I repeated the monitor power-cycle test with 615.71.09, then downgraded to 610.57.04, where the monitor recovers normally. Comparing the journal immediately around the off/on transitions reveals explicit KWin OpenGL errors with 615.71.09 that are absent from the working 610.57.04 cycle.
Both compared boots use kernel 7.2.6-arch2-1. The monitor is the ASUS PG27AQDP on DP-2 / card1-DP-2, with the previously reported 2560×1440 / 480 Hz configuration.
Compared boot IDs:
b1da6bd64eba4bdf8dafd060615da123.b9d607c4e4fe43d9b40436d3cd352f7f.There was an intermediate boot with 615.71.09 in which the downgrade was performed; it is not the failing power-cycle capture compared below. Versions were verified from the loaded kernel module messages, not just the installed packages.
Errors on 615.71.09
The following pair occurs twice, once during power-off and again during power-on:
The first pair is timestamped
Sep 25 07:52:04in the wall-clock journal. Timelines below use seconds since boot because the system clock was adjusted during startup. They are abbreviated chronological summaries, with message text shortened where indicated.Power-off comparison
615.71.09:
610.57.04:
No texture allocation or framebuffer-completeness errors occur in the working cycle. The first explicit graphics error on 615.71.09 therefore already occurs during power-off, before turning the monitor back on.
Power-on comparison
615.71.09:
The USB hub, keyboard and mouse re-enumerate around +58–60 s, but the journal contains no subsequent
DDCA_EVENT_DISPLAY_CONNECTEDorDisplay redetection finished.for this transition. Another USB disconnect is recorded at +75.7 s; a reboot is requested over SSH at +104.6 s, and the journal ends during service shutdown.610.57.04:
Interpretation and limits
GL_OUT_OF_MEMORYdemonstrates a graphics allocation failure, not by itself proof that physical VRAM was exhausted. No contemporaneous VRAM usage measurement was captured.Adding connected display with bus 4; the missing completion of that sequence should not be treated as the first observed fault.There are no outputs - creating placeholder screenand the USB disconnect/reconnect messages also occur in the successful cycle and are not diagnostic on their own.Lost display notification, Xid or 122-second hung-task report. It lasts only about 105 seconds, so it does not provide a new hung-task stack comparable to the September 24 captures in the issue description. Whether the OpenGL failures and the previously captured DisplayPort/GSP wait have the same underlying cause remains unconfirmed.jorjun commentedon Sep 27, 2026
Same driver version, same failure family, different GPU/stack — adding independent evidence and two symptoms not yet in this thread.
Environment
7.2.5-3-omarchySymptom 1: Xid 16 flood + nvkms kthread hung on the pmlock, ~2h before your stack shape
Sep 26boot, hotplug of the USB-C/DP adapter at 15:06:Hung-task reports repeat 15:54→16:12 (~2 min apart, 21 occurrences). Boot ended in a clean shutdown at 22:00; SSH-equivalent access (other TTYs) stayed alive.
Your captured stack has the compositor stuck in
nvkms_ioctl_from_kapi_try_pmlockinside an atomic modeset waiting on a GSP RPC; mine is the mirror image — the nvkms kthread (_main_loop→nvkms_kthread_q_callback) blocked on the semaphore while the compositor holds it. Same lock, opposite side — consistent with the pmlock/GSP-wait deadlock you captured.Symptom 2: after a later hotplug, every modeset silently no-ops (no kernel error at all)
Next boot, after a hotplug cycle, on the same connector (
card1-DP-1):Every request returned ok from the compositor; kernel logged zero nvidia/drm errors; no blank. The mode is simply never applied. Notably small modes (1920x1080@60 ≈ 4.5 Gbit/s payload) are refused too, so this is not a link-bandwidth ceiling — the connector appears pinned to the trained mode.
Symptom 3: DP hotplug of a different device produces no DRM connector event
With the session live, disconnecting the adapter and connecting a different DP sink (VITURE XR glasses presenting 1920x1080) enumerated its USB side but produced no DRM connector event for 73 s — no nvidia/drm/hotplug messages, connector kept the stale EDID of the previously trained device. This matches the missing
DDCA_EVENT_DISPLAY_CONNECTED/ "Display redetection finished." completion in your +58 s capture: with 615.71.09 the hotplug handshake starts (USB re-enumerates) but the DP side never re-trains or reports.What this adds
Recovery on my machine required a full reboot; reload/replug did not clear the modeset lockout.
Filed by GLM (glm-5.3-flash) via opencode CLI.
vatodevops commentedon Sep 28, 2026
Another data point for this regression, with a full hung-task stack that shows the hotplug worker spinning inside the GSP RPC wait at boot, with no monitor power-cycling involved.
Environment
eDP-1) + RTX 4070 Laptop GPU (AD106M,10de:2860, VBIOS 95.06.1D.00.19) driving two external monitors (HDMI-A-1 + DP-3)7.2.8-1-cachyos,nvidia-drm modeset=1plasma-login-manager6.7.4 greeterSymptom
Intermittent at boot: the greeter never appears, only a blinking text cursor. VT switching (Ctrl+Alt+F2) doesn't respond, the laptop heats up (one core pinned at 100%), and a short power-button press still gives a clean systemd shutdown. Two failures in a row today right after a kernel update (7.2.7 → 7.2.8, module rebuilt), then the third boot was fine. Also seen on 23/09. Not seen on 610.x.
The greeter's
kwin_waylandtimes out at startup, and then evenSIGKILLcan't kill it (Processes still around after final SIGKILL). This also happened when the greeter was restricted to the Intel GPU only (KWIN_DRM_DEVICESpointing at the i915 card), because KWin still blocks on the nvidia-drm side while exiting.Stack (hung-task detector, ~4 min after boot)
KWin is blocked on a mutex held by the nvidia-drm hotplug worker:
The owner is running (state R), not sleeping: it's busy-polling the GSP while validating a mode from the hotplug handler:
So the IMP check (
nvEvoIsModePossibleC3→ RM control → GSP RPC) never gets a reply,kgspRecvPollnever gives up, and the worker holds the DRM lock indefinitely. That explains the unkillable compositor, the dead VT switching, and the heat.nvidia-powerdalso times out on shutdown in the failing boots.Other notes:
Unable to read EDID for display device DP-2appears on every boot, good and bad, so it doesn't discriminate.nvidia-modeset: WARNING: GPU:0: Lost display notificationjust before the compositor started (it's absent from good boots).Full journals of both failing boots are available if useful.
yungwood commentedon Sep 29, 2026
Another data point: DisplayPort reconnect fails on 615.71.09 but passed after downgrading to 610.57.04, with an explicit GSP timeout in the post-modeset display-capability cache update.
I initially encountered this when running a script to change AOC from 4k to 1080p and disabled HDMI before playing a game. Multiple subsequent script runs passed, whereas DP reconnect reliably reproduced the failure.
Environment
7.2.7-zen1, Hyprland0.56.2-3, Aquamarine0.15.1-1Reproduction and comparison
Unplug AOC DisplayPort, wait ~10 seconds, reconnect; both monitors initially enabled.
Stack
Both failures logged
Lost display notification, then Xid 119 waiting for function 76 (GSP_RM_CONTROL), control0x73114e(NV0073_CTRL_CMD_DFP_UPDATE_DYNAMIC_DFP_CACHE):Subsequent controls
0x730280and0x731360timed out, followed by Xid 154 / PF FLR. This adds a post-modeset timeout path to the pre-modeset/link-training stack in the original report.Completed
nvidia-bug-report.sh --safe-modereports collected over SSH during multiple failed states are available.Romancc commentedon Oct 1, 2026
Same regression here on Ada desktop (RTX 4080). One extra data point that may help: it depends on the refresh rate, i.e. on link bandwidth / DSC.
Environment
10de:2704), open kernel moduleResults
So on 615.71.09, dropping the OLED from 360 Hz to 240 Hz avoids the hang. That is a usable workaround for anyone affected.
The first occurrence happened without touching the power button, ~10 min after login (Plasma screen-off/DPMS timeout). The OLED's sleep/wake cycle is probably enough to trigger it, which matches #1371.
Stack
Same shape as the original report.
kwin_waylandstays in state R (NMI backtrace via sysrq-l):Blocked behind it:
nvidia-modeset/kthread_q(semaphore held by kwin_wayland), DRM clients indrm_release -> nv_drm_revoke_modeset_permission, NVML clients inos_acquire_rwlock_*. No Xid and no GSP timeout message. After a few minutes:nvidia-modeset: WARNING: GPU:0: Lost display notification.Before the hang the OLED sends several HPD events (connected, then disconnected, then connected again within ~25 s). The
enableFlushframe in the retrain path looks like the scenario described in #1405 / #1406 (detach dropped indpPreModeset()while unplugged, next attach treated as a retrain on an active head). Here, though, it ends in a GSP RPC hang instead of a black screen.nvidia-bug-report.sh --safe-mode --extra-system-datacaptured during the hang is attached.nvidia-bug-report-safe.log.gz
HiroGitea commentedon Oct 2, 2026
@Romancc thanks for linking this. Your stack goes through the same
trainLinkOptimized()→enableFlush()path I hit in #1405, and both of our failing modes use DSC (4K@160 here; 1440p@360 doesn't fit in HBR3 without it on a 4080). On my RTX 5070 Ti the flush control fails right away and the screen stays black. On your 4080 the link training RPC after it never seems to return.If you can build the modules, could you try #1406 with the OLED at 360 Hz? Only
nvidia-modeset.kochanges. On CachyOS the kernel is built with clang, so I neededmake modules -j$(nproc) LLVM=1 CC=clang LD=ld.lld. If power off/on no longer hangs, that would confirm the dropped detach is behind this hang too.ksc98 commentedon Oct 3, 2026
Another data point on Ada (RTX 4090) with Hyprland 0.56.2, triggered by a KVM switch. The same machine has now hung through both stacks reported here: the post-modeset
rmUpdateDynamicDfpCachepath (which timed out with Xid 119) and the pre-modesettrainLinkOptimized→enableFlushpath (which hung for over 10 minutes without ever tripping the GSP timeout).By the way, driver
610.57.04doesn't have this issue. I pinned to 610 for a while but wanted to do full due diligence on the 615 issue so here we are.@HiroGitea: I patched my
nvidia-modeset.koso I'll observe if this fixes the issue!The current hypothesis is that starting with 615.71.09, if the monitor is disconnected at the moment the compositor turns its screen off, the driver silently drops the detach and keeps treating the screen as active.
Anything that makes the monitor disappear while the system stays up can cause this: a power cycle, an input switch, the monitor's own sleep, a KVM switch, or an unplugged cable.
When the monitor comes back, the driver treats the reconnect as a retrain of a live screen (
enableFlush) instead of a fresh setup.That retrain is where things go wrong: on some GPUs the flush fails and the screen stays black, and on others link training against GSP stalls and the compositor hangs inside the atomic commit.
Environment
nvidia-drm modeset=1 fbdev=17.2.8-2-cachyos(clang-built), Hyprland 0.56.2 (Aquamarine, atomic)05e3:0610) both go through a KVM. Switching away drops HPD and the hub, and switching back restores both while the system stays up.Hang 1: pre-modeset link training, no Xid
No Xid of any kind between the hang and the reboot more than 10 minutes later. Hyprland stayed in
state:Rinside a single atomic commit, polling GSP:This is the same call path as @Romancc's stack, including
enableFlush, which fits the #1405 / #1406 theory (detach dropped while the sink was unplugged, next attach treated as a retrain). Here the trigger is a KVM switch rather than a monitor power cycle or input switch.Observations during the hang:
nvidia-smihangs.kill -9on the compositor never lands:SigPnd: 0x100stayed pending for 30+ s because the atomic commit ioctl never returned. The GPU'sreset_methodisflr bus, but an FLR orrmmodcan't work while that task holds the semaphore, so I didn't try one. A reboot was the only recovery.Hang 2: post-modeset path, timed out
Same machine and driver, also after a KVM switch:
via
nvDPPostSetMode → dpPostModeset → notifyAttachEnd → rmUpdateDynamicDfpCache, the same control (0x73114e) @yungwood reported. Also reboot-only.So on one box, the
rmUpdateDynamicDfpCacheRPC hit the 45 s GSP timeout, while the link-training hang never produced an Xid. ReadingkgspRecvPoll_IMPLagainst the stack offsets, the poll loop was cycling past its timeout check (kdispApplyAggressiveVblankHandlingWaronly runs aftergpuCheckTimeoutpasses), so it looks like no singleNV0073_CTRL_CMD_DP_CTRL(0x731343) exceeded 45 s. Instead the commit spent minutes in link-training fallback (trainLinkOptimizedretryingtrain()), each GSP call slow but under the timeout. That would explain why neither the RPC timeout norRmGspRpcTimeoutGpuResetThresholdcan rescue this variant.Full kernel journals for both hangs are available. I couldn't run
nvidia-bug-report.shduring the hang becausenvidia-smiwas wedged.fix(boxy): pin nvidia 610.57.04 to stop DisplayPort hotplug deadlock
mikkorantalainen commentedon Oct 15, 2026
I'm seeing similar issue on Ubuntu 24.04 LTS + XFCE with Nvidia version 615.71.09. The older version 610.57.04 seemed to work correctly so there has been major regression between those versions (except this issue that I have to workaround with custom Xorg build: canonical/nvidia-graphics-drivers#92 (comment)).
My display is connected via DisplayPort to RTX 3060 12 GB and in my case the trigger seems to be S3 sleep. It still looks like disconnected monitor to the GPU, too, because my monitor (LG 27GN800-B) appears as disconnected cable whenever it enters the deepest DPMS state. The issue seems to be yet another race condition in Nvidia drivers because it seems to fail with probability around 1/4 (I'm using package
linux-lowlatency-7.0to run the latest supported lowlatency kernel variant which may trigger race conditions more easily).Unfortunately, Ubuntu 24.04 LTS has removed version 610 of Nvidia drivers: installing package
nvidia-driver-610-openresults innvidia-driver-615-opengetting installed because packagenvidia-driver-610-openis now basically an alias (transitional package only).I had to downgrade back to version 595 instead to have a stable system.
witgelm commentedon Oct 18, 2026
Another data point on Ada, this time on 615.78.08, so the fix in 615.78 doesn't seem to cover every path. In my case the trigger was S3 resume with
NVreg_UseKernelSuspendNotifiers=1(the default on 615).Setup
mem_sleep= deep)What happened
After resume the monitor powered on but stayed black. The kernel resumed devices and thawed tasks, but
PM: suspend exitwas never logged (it comes after the PM_POST_SUSPEND notifiers). About 4 s later:nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
The rest of the system kept running (journald was still writing), and I had to do a hard reset. With the kernel notifiers on,
nvidia-suspend.servicewas a no-op: it finished in about 5 ms, because/proc/driver/nvidia/suspenddoesn't exist in that mode.Workaround that works
options nvidia NVreg_UseKernelSuspendNotifiers=0 NVreg_PreserveVideoMemoryAllocations=1
After that, the systemd services do the save/restore (
nvidia-suspendtakes about 1.1 s),PM: suspend exitis logged,nvidia-resume.serviceruns, and the display comes back normally.So far I've seen the hang once, so I can't say whether it happens on every resume with the notifiers on. I can switch back to
UseKernelSuspendNotifiers=1and capturenvidia-bug-report.shplus a SysRq-W blocked-task dump if that would help.