615.71.09 regression: DisplayPort monitor power cycling hangs KWin in GSP RPC wait; nvidia-modeset blocked, shutdown hangs (RTX 4070)

[Lubix89]

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 PG27AQDP in its EDID.
• Connector: DisplayPort, card1-DP-2 in DRM/sysfs, DP-2 in KScreen. PowerDevil/ddcutil recorded DDCA_EVENT_DISPLAY_DISCONNECTED for card1-DP-2 at 07:35:43 in affected boot 96e603de58ef43ea93a3de2ce471f069, with /dev/i2c-4 and ddc 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, on card1-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, path 1-5), a downstream GenesysLogic hub (05e3:0610, path 1-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

1. Boot with NVIDIA open kernel modules and driver 615.71.09.
2. 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.
3. Physically turn the main monitor off, then back on.
4. Repeat the off/on cycle.
5. In my reproduction, the second cycle leaves the screens black.
6. 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.

[Lubix89]

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:

• 615.71.09: b1da6bd64eba4bdf8dafd060615da123.
• 610.57.04: 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:

kwin_wayland[989]: 0x505: GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.
kwin_wayland[989]: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"

The first pair is timestamped Sep 25 07:52:04 in 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:

+33.737 s  Monitor USB hub disconnects; keyboard/mouse disconnect too.
+34.290 s  PowerDevil receives DRM change/hotplug event.
+34.327 s  KWin: GL_OUT_OF_MEMORY ... Failed to allocate memory for texture.
+34.327 s  KWin: GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT
+34.329 s  KDE applications: There are no outputs - creating placeholder screen
+34.851 s  PowerDevil: DDCA_EVENT_DISPLAY_DISCONNECTED, card1-DP-2,
                       io_path:/dev/i2c-4, ddc working: false

610.57.04:

+30.475 s  Monitor USB hub disconnects; keyboard/mouse disconnect too.
+31.028 s  PowerDevil receives DRM change/hotplug event.
+31.087 s  KDE applications: There are no outputs - creating placeholder screen
+31.593 s  PowerDevil: DDCA_EVENT_DISPLAY_DISCONNECTED, card1-DP-2,
                       io_path:/dev/i2c-4, ddc working: false

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:

+57.791 s  PowerDevil receives DRM change/hotplug event.
+57.975 s  xsettingsd: Reloading configuration
+58.086 s  KWin: GL_OUT_OF_MEMORY ... Failed to allocate memory for texture.
+58.086 s  KWin: GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT
+58.173 s  PowerDevil: Adding connected display with bus 4
+58.196 s  KDE applications: There are no outputs - creating placeholder screen

The USB hub, keyboard and mouse re-enumerate around +58–60 s, but the journal contains no subsequent DDCA_EVENT_DISPLAY_CONNECTED or Display 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:

+47.322 s  PowerDevil receives DRM change/hotplug event.
+47.526 s  xsettingsd: Reloading configuration
+47.723 s  PowerDevil: Adding connected display with bus 4
+47.747 s  KDE applications: There are no outputs - creating placeholder screen
+48.043 s  PowerDevil: DDCA_EVENT_DISPLAY_CONNECTED, card1-DP-2,
                       io_path:/dev/i2c-4, ddc working: true
+48.063 s  PowerDevil: Buses with edid: 3 4
+48.740 s  PowerDevil: Display redetection finished.

Interpretation and limits

• The earliest explicit anomalous messages in the compared transitions are KWin's texture allocation failure and incomplete framebuffer, present with 615.71.09 and absent with 610.57.04. These failures are associated with the loss of image and are consistent with a rendering failure, but the logs alone do not prove whether they initiate the problem or are consequences of another driver failure.
• GL_OUT_OF_MEMORY demonstrates a graphics allocation failure, not by itself proof that physical VRAM was exhausted. No contemporaneous VRAM usage measurement was captured.
• A DRM hotplug event does arrive with both drivers. With 615.71.09, the KWin errors precede PowerDevil's 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 screen and the USB disconnect/reconnect messages also occur in the successful cycle and are not diagnostic on their own.
• This short failing boot has no 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.