RTX 3060 Ti / 610.57.04: recurring Xid 79 and frozen display, including while monitor stays on

[conscientiousness]

Summary

A GeForce RTX 3060 Ti system has a persistent frozen display: the monitor remains lit with an old frame, and local keyboard/mouse interaction does not work. SSH and remote Herdr terminal sessions remain usable.

The user reports that this frequently happens after physically switching the monitor off, leaving it off for a while, then switching it on again. The exact power-cycle time for this captured incident was not recorded, so this trigger is user-reported rather than independently correlated to the journal. No suspend/resume transition was found in the current-boot journal searches.

This is a request for recovery/diagnostic and routing guidance. We have not tested the proprietary kernel module of the same version, and are not claiming the failure is specific to the open module. We are using Q&A rather than checking that unverified confirmation in the issue form.

Environment

• Omarchy 4.0.4-1 / Arch Linux
• Kernel: 7.2.5-3-omarchy (packaged release kernel)
• GPU: NVIDIA GA104 / GeForce RTX 3060 Ti Lite Hash Rate, PCI 10de:2489
• CPU: AMD Ryzen 5 5600X
• Loaded open kernel module: 610.57.04
• nvidia-open-dkms and nvidia-utils: 610.57.04-1
• Hyprland 0.56.2-2, Aquamarine 0.15.0
• Custom user Hyprland configuration creates a persistent headless output named Sunshine for RustDesk, with a DP-1 rule mirroring that output. Stock Hyprland configuration has not been compared. The subsequent SDDM greeter failures use SDDM's separate configuration.
• Monitor model and exact off duration: not yet recorded
• Proprietary-driver, stock Arch kernel, and LTS-kernel comparisons: not performed

Evidence and chronology

Times below are local UTC+08:00. On 2026-10-06:

20:16:01 NVRM: Xid (PCI:0000:07:00): 79, GPU has fallen off the bus.
20:16:01 NVRM: Xid (PCI:0000:07:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)
20:16:01 NVRM: GPU lost from the bus [NV_ERR_GPU_IS_LOST]
20:20:14 Hyprland SIGABRT in Render::GL::CHyprOpenGLImpl::begin
20:20:17 [nvidia-drm] Flip event timeout on head 0
20:20:23 nvidia-modeset: ERROR: GPU:0: Error while waiting for GPU progress: 0x0000c67e:6 2:0:4048:4040

The progress error continues about every five seconds into October 7. Xid 154 selects a recovery action; it does not prove an FLR was executed or completed.

The old systemd-logind process and nvidia-modeset/kthread_q remain in D state. Root kernel stacks captured during recovery:

nvidia-modeset/kthread_q:
  nvkms_kthread_q_callback+0xb1/0x170 [nvidia_modeset]
  _main_loop+0x114/0x170 [nvidia_modeset]
  kthread+0xe4/0x120

old systemd-logind:
  drm_open+0x5c/0x110
  drm_stub_open+0xb2/0x110
  chrdev_open+0xcb/0x280
  do_dentry_open+0x13d/0x4a0
  vfs_open+0x30/0x110
  path_openat+0x49a/0x14d0
  do_file_open+0x117/0x1d0
  do_sys_openat2+0x7d/0xe0
  __x64_sys_openat+0x61/0xb0

PCI config space remains readable and identifies 10de:2489, but the command register is 0x0000 and BAR address bits are zero. The kernel resource table still lists allocated apertures. This does not establish the cause of the lost state. reset_method reads flr bus.

Recovery attempts

On 2026-10-07 at 19:42, SDDM was stopped successfully to end a secondary greeter crash loop. A root fuser check found no GPU/DRM device-node clients before attempting:

nvidia-smi --gpu-reset -i 0000:07:00.0
Unable to determine the device handle for GPU0: 0000:07:00.0: Unknown Error
No devices found.
[exit status 2]

At 19:53, restarting SDDM did not recover the desktop: the service was active but its log stopped at Initializing, with no Hyprland process/live instance. nvidia-smi -L still reports Unknown Error and the GPU progress errors continue.

No raw PCI reset, bus reset, unbind, forced module removal, driver/kernel changes, or reboot was performed. The user currently needs to preserve running remote work. A reboot's effect has not been tested. No OOM explanation was found, and memory/disk space remain available.

Questions

1. Is this Xid 79 plus readable-but-cleared PCI configuration consistent with a known 610.57.04 failure, or which evidence would best distinguish driver/firmware from PCIe/power/hardware causes?
2. Is there a supported live recovery when NVML cannot obtain a device handle and a DRM open is blocked, or is restarting the host required in this state?
3. Should this be moved to the Linux graphics forum, or tracked under an existing report?

We have not yet collected nvidia-bug-report.log.gz; root-captured stacks and the failure excerpts above are the available evidence. Please advise which additional capture is most useful in this still-failed state.

Related reports, not confirmed duplicates:

• Display freezes on display blank — KMS thread blocked on semaphore held by nvidia-modeset stuck in nvDIFRPrefetchSurfaces (610.57.04, still present) #1289: same driver version/frozen-frame symptom, different stack; original reporter later corrected the reliable trigger to suspend/resume.
• 615.71.09 regression: DisplayPort monitor power cycling hangs KWin in GSP RPC wait; nvidia-modeset blocked, shutdown hangs (RTX 4070) #1392: physical monitor power-cycle trigger, but 615.71.09 and a different stack.
• System Freeze on Wake-up omacom/omarchy#26: older broad wake-up thread; not established as this failure.

The GPU accessibility failure is confirmed; its initiating cause is not. No assertion is made that this is an Omarchy configuration defect or an open-module-only bug.

Filed by GPT-6 via Codex, at the user's request.

[conscientiousness]

Recurrence while the monitor remained ON — October 9

The same GPU accessibility failure recurred on October 9 while the physical monitor was already on, according to the user. No off/on transition was reported for this recurrence. This means physical monitor power cycling is not established as a necessary trigger.

There is also a healthy control observation on the same boot: after rebooting on October 8, the GPU and compositor responded normally. A read-only recorder captured the ASUS VG27AQL1A on DisplayPort reconnecting at 16:08:39 (+08:00) and observed the following 10 minutes: 0 GPU query failures, 0 Hyprland IPC failures, and 0 matching kernel alerts. The user confirmed normal display and input. Driver/kernel/configuration versions stayed the same.

On October 9, on that same boot, the first Xid appears at 15:57:49 (+08:00):

15:57:49 NVRM: Xid (PCI:0000:07:00): 79, GPU has fallen off the bus.
15:57:49 NVRM: Xid (PCI:0000:07:00): 154, GPU recovery action changed from 0x0 (None) to 0x1 (PF FLR)
15:57:50 User-session Hyprland (PID 1261) aborts
15:58:04 nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x0000c67e:6:0:0x0000000f

The display engine error continues about every 10 seconds. The new Hyprland crash stack is:

Render::GL::CGLFramebuffer::internalAlloc
Render::IFramebuffer::alloc
Render::IHyprRenderer::makeSnapshotFB
Desktop::View::CWindow::unmapWindow

Several graphics clients also fail in NVIDIA EGL code during the same failure. We are not attributing the initiating Xid to the window-unmap operation or a particular client from this sequence alone.

Current nvidia-smi reports:

Unable to determine the device handle for GPU0: 0000:07:00.0: Unknown Error
No devices were found

Again, PCI configuration remains readable (10de:2489), with command register 0x0000 and BAR address bits zero. The modeset kernel thread is in state S this time, rather than D during the previous failed boot. No nearby AER/PCIe Bus Error or suspend/resume event was found in the kernel timeline. Memory is available (about 25 GiB available); no OOM explanation was found. Remote Herdr/SSH access remains alive.

No reset, forced unload, raw PCI changes, driver/kernel update or reboot has been performed for this recurrence yet. The first Xid precedes Hyprland's crash by approximately one second, but the initiating driver/firmware/PCIe/power/hardware cause remains unresolved.

The initial monitor-cycle association is therefore insufficient to explain all occurrences. Is this accessible-but-cleared PCI configuration useful for narrowing a known R610 failure, and which driver/kernel comparison should be tested first?

Follow-up prepared by GPT-6 via Codex, at the user's request to report this failure.