You are not logged in.
I am using GNOME + Wayland + NVIDIA (RTX 5070 with nvidia-open drivers). Sometimes when I resume from suspend, my display locks up after about 3 minutes, and I cannot even shift to another TTY. I haven't be able to find any hints in journalctl as to the cause of these lockups. UseKernelSuspendNotifiers and TemporaryFilePath are set correctly. I have not enabled NVIDIA's resume or suspend services since my driver is from the 610 branch.
I have been able to use REISUB when the system locks up, and I think the freeze is restricted to my graphics and is probably and NVIDIA issue.
Currently, I have disabled suspend in GNOME settings in hopes that stops lock ups.
However, I would like to know if there are other options to troubleshoot or fix this issue.
PS. I am running a AMD Ryzen 9 9950X3D on an MSI MAG B850 Tomahawk Max WIFI if that makes a difference.
Offline
I have been able to use REISUB when the system locks up
So the journal of the previous (freezing) boot might provide hints as to what's going wrong.
I haven't be able to find any hints in journalctl
If you want to give everyone else a fair chance to see what's up, you'll have to post the journal from a boot after the freeze/REISUB ![]()
after about 3 minutes
2 systemd timeouts, but might be coincidental.
Offline
Good point. Here is the journal of the most recent boot that froze and I was able to REISUB.
https://gist.githubusercontent.com/reed … ournal.txt
Key time points:
Aug 09 19:41:55 = System goes to sleep
Aug 09 19:44:20 = System begins to wake up and I log in again to use Firefox.
Aug 09 19:45:43 = System has locked up (I press the power button to see if I can do a clean shutdown)
Aug 09 19:47:01 = I start doing REISUB
Last edited by reedacartwright (2026-08-10 06:53:18)
Offline
So there're multiple sleep cycles but only one really long one
Aug 09 00:17:10 ajax systemd[1]: Reached target Sleep.
Aug 09 17:06:08 ajax systemd[1]: Stopped target Sleep.which isn't the breaking one, so it's unlikely to be about the VRAM preservation.
The freeze seems to come in response to
Aug 09 19:45:19 ajax NetworkManager[764]: <info> [1786329919.2092] device (wlp6s0): set-hw-addr: set MAC address to 8A:DC:A9:31:F9:F1 (scanning)
Aug 09 19:45:19 ajax NetworkManager[764]: <info> [1786329919.2096] device (wlp6s0): supplicant interface state: disconnected -> inactive
Aug 09 19:45:19 ajax wpa_supplicant[2718]: wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
Aug 09 19:45:19 ajax NetworkManager[764]: <info> [1786329919.2096] device (p2p-dev-wlp6s0): supplicant management interface state: disconnected -> inactive
Aug 09 19:45:19 ajax wpa_supplicant[2718]: wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=USNMs scanning habits?
I cannot even shift to another TTY
Can you still ssh into the frozen system?
Can you then chvt the TTY?
Offline
I'll see if I can do that the next time it happens.
Offline
It locked up again and I was able the ssh into it. chvt did not work.
nvidia-modeset/kthread_q is showing 100% CPU usage.
Here is a copy of dmesg output.
https://gist.githubusercontent.com/reed … /dmesg.txt
Here is the first relevant error message
[29980.144013] INFO: task KMS thread:4076 blocked for more than 122 seconds.
[29980.144020] Tainted: G OE 7.1.6-arch1-1 #1
[29980.144022] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[29980.144023] task:KMS thread state:D stack:0 pid:4076 tgid:4056 ppid:3675 task_flags:0x400040 flags:0x00080000
[29980.144028] Call Trace:
[29980.144030] <TASK>
[29980.144032] __schedule+0x459/0x1870
[29980.144041] schedule+0x27/0xa0
[29980.144043] schedule_timeout+0xdc/0x120
[29980.144046] __down_common+0xfe/0x340
[29980.144049] down+0x53/0x70
[29980.144053] nvkms_ioctl_from_kapi_try_pmlock+0x4a/0xa0 [nvidia_modeset d9e0923f1cbdc448aa231f5fe0c34c7dbae31ce6]
[29980.144075] ApplyModeSetConfig+0x5ed/0xda0 [nvidia_modeset d9e0923f1cbdc448aa231f5fe0c34c7dbae31ce6]
[29980.144100] nv_drm_atomic_apply_modeset_config+0x7b0/0x890 [nvidia_drm 0b39f5881113846bd2e991e2769896275136bdd1]
[29980.144107] drm_atomic_check_only+0x5c4/0x9f0
[29980.144111] drm_atomic_nonblocking_commit+0x17/0x70
[29980.144113] drm_mode_atomic_ioctl+0xb58/0xdb0
[29980.144116] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[29980.144118] drm_ioctl_kernel+0xae/0x100
[29980.144122] drm_ioctl+0x2d8/0x570
[29980.144124] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[29980.144127] __x64_sys_ioctl+0xb9/0x100
[29980.144130] do_syscall_64+0xaa/0x660
[29980.144133] ? do_syscall_64+0x252/0x660
[29980.144134] ? security_file_permission+0x48/0x130
[29980.144138] ? vfs_read+0x34d/0x490
[29980.144141] ? ksys_read+0xdd/0x110
[29980.144143] ? do_syscall_64+0xaa/0x660
[29980.144145] ? do_futex+0x11f/0x190
[29980.144148] ? __x64_sys_futex+0x136/0x220
[29980.144150] ? ksys_read+0xdd/0x110
[29980.144152] ? do_syscall_64+0xaa/0x660
[29980.144153] ? ksys_read+0xdd/0x110
[29980.144155] ? do_syscall_64+0xaa/0x660
[29980.144157] ? do_syscall_64+0x252/0x660
[29980.144158] ? do_syscall_64+0xaa/0x660
[29980.144160] ? do_syscall_64+0x5f/0x660
[29980.144161] ? __irq_exit_rcu+0x48/0x100
[29980.144164] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[29980.144166] RIP: 0033:0x7f8b0ad1abfd
[29980.144184] RSP: 002b:00007f8ae8983ee0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[29980.144186] RAX: ffffffffffffffda RBX: 00007f8abc19b850 RCX: 00007f8b0ad1abfd
[29980.144187] RDX: 00007f8ae8983f80 RSI: 00000000c03864bc RDI: 000000000000000c
[29980.144188] RBP: 00007f8ae8983f30 R08: 0000000000000000 R09: 00000000000000c2
[29980.144189] R10: 0000000000000ff0 R11: 0000000000000246 R12: 00007f8ae8983f80
[29980.144190] R13: 00000000c03864bc R14: 000000000000000c R15: 00007f8ac4032730
[29980.144191] </TASK>Last edited by reedacartwright (2026-08-12 04:01:25)
Offline
https://github.com/NVIDIA/open-gpu-kern … ssues/1167
But likely the main problem is older, https://bbs.archlinux.org/viewtopic.php?id=307911 and not sleep specific, https://github.com/NVIDIA/open-gpu-kern … issues/832 & https://github.com/NVIDIA/open-gpu-kern … ssues/1246
This likely relates to your output(s) - how and when they're de/reactivated, maybe frequency/VRR
for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; doneYou'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/
Is there a difference in the suspend triggers between the succeeding and failing ones (notably explicit vs implicit and screenlockers involved)?
Offline
I only have one monitor attached, and I did not see anything notable when I ran that command. But I probably do not know what I am looking for.
Offline
The idea was to just post the output ![]()
Offline
Here's the output.
/sys/class/drm/card1
/sys/class/drm/card1/edid: No such file or directory
=================
/sys/class/drm/card1-DP-1
EDID of '/sys/class/drm/card1-DP-1/edid' was empty.
=================
/sys/class/drm/card1-DP-2
EDID of '/sys/class/drm/card1-DP-2/edid' was empty.
=================
/sys/class/drm/card1-DP-3
edid-decode (hex):
00 ff ff ff ff ff ff 00 10 ac 41 a2 4c 54 38 30
09 24 01 04 b5 50 21 78 3b 74 b5 af 4f 42 a9 24
0e 50 54 a5 4b 00 71 4f 81 c0 81 cf 81 00 81 80
a9 40 d1 c0 01 01 e7 7c 70 a0 d0 a0 29 50 30 20
3a 00 20 4f 31 00 00 1a 00 00 00 ff 00 47 30 4c
4e 56 38 34 0a 20 20 20 20 20 00 00 00 fc 00 44
45 4c 4c 20 55 33 34 32 35 57 45 0a 00 00 00 fd
00 30 78 b9 b9 43 01 0a 20 20 20 20 20 20 02 e4
02 03 17 f1 47 4c 5a 45 4b 10 04 1f 23 09 07 07
83 01 00 00 e2 00 ea 56 5e 00 a0 a0 a0 29 50 30
20 35 00 20 4f 31 00 00 1a 4d d2 70 7e d0 a0 46
50 0e 20 3a 00 20 4f 31 00 00 1a 7e 48 00 e0 a0
38 1f 40 40 40 3a 00 20 4f 31 00 00 1a 02 3a 80
18 71 38 2d 40 58 2c 45 00 20 4f 31 00 00 1e 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76
70 12 79 03 00 03 01 14 33 04 01 06 6f 0d c7 00
2f 80 1f 00 9f 05 54 00 02 00 09 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 90
----------------
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: DEL
Model: 41537
Serial Number: 808997964 (0x3038544c)
Made in: week 9 of 2026
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 10
DisplayPort interface
Maximum image size: 80 cm x 33 cm
Gamma: 2.20
DPMS levels: Off
Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2
First detailed timing includes the native pixel format and preferred refresh rate
Display supports continuous frequencies
Color Characteristics:
Red : 0.6845, 0.3115
Green: 0.2587, 0.6601
Blue : 0.1425, 0.0576
White: 0.3134, 0.3291
Established Timings I & II:
IBM : 720x400 70.081663 Hz 9:5 31.467 kHz 28.320000 MHz
DMT 0x04: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz
DMT 0x06: 640x480 75.000000 Hz 4:3 37.500 kHz 31.500000 MHz
DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz
DMT 0x0b: 800x600 75.000000 Hz 4:3 46.875 kHz 49.500000 MHz
DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz 65.000000 MHz
DMT 0x12: 1024x768 75.028582 Hz 4:3 60.023 kHz 78.750000 MHz
DMT 0x24: 1280x1024 75.024675 Hz 5:4 79.976 kHz 135.000000 MHz
Standard Timings:
DMT 0x15: 1152x864 75.000000 Hz 4:3 67.500 kHz 108.000000 MHz
DMT 0x55: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz
GTF : 1280x720 74.999686 Hz 16:9 56.400 kHz 95.654000 MHz
DMT 0x1c: 1280x800 59.810326 Hz 16:10 49.702 kHz 83.500000 MHz
DMT 0x23: 1280x1024 60.019740 Hz 5:4 63.981 kHz 108.000000 MHz
DMT 0x33: 1600x1200 60.000000 Hz 4:3 75.000 kHz 162.000000 MHz
DMT 0x52: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
Detailed Timing Descriptors:
DTD 1: 3440x1440 59.972616 Hz 43:18 88.819 kHz 319.750000 MHz (800 mm x 335 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 28 Vpol N
Display Product Serial Number: 'G0LNV84'
Display Product Name: 'DELL U3425WE'
Display Range Limits:
Monitor ranges (Range Limits Only): 48-120 Hz V, 185-185 kHz H, max dotclock 670 MHz
Extension blocks: 2
Checksum: 0xe4
----------------
Block 1, CTA-861 Extension Block:
Revision: 3
Underscans IT Video Formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
Native detailed modes: 1
Video Data Block:
VIC 76: 1920x1080 60.000000 Hz 64:27 67.500 kHz 148.500000 MHz
VIC 90: 2560x1080 60.000000 Hz 64:27 66.000 kHz 198.000000 MHz
VIC 69: 1280x720 60.000000 Hz 64:27 45.000 kHz 74.250000 MHz
VIC 75: 1920x1080 50.000000 Hz 64:27 56.250 kHz 148.500000 MHz
VIC 16: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz
VIC 4: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz
VIC 31: 1920x1080 50.000000 Hz 16:9 56.250 kHz 148.500000 MHz
Audio Data Block:
Linear PCM:
Max channels: 2
Supported sample rates (kHz): 48 44.1 32
Supported sample sizes (bits): 24 20 16
Speaker Allocation Data Block:
FL/FR - Front Left/Right
Video Capability Data Block:
YCbCr quantization: Selectable (via AVI YQ)
RGB quantization: Selectable (via AVI Q)
PT scan behavior: Always Underscanned
IT scan behavior: Always Underscanned
CE scan behavior: Always Underscanned
Detailed Timing Descriptors:
DTD 2: 2560x1440 59.950550 Hz 16:9 88.787 kHz 241.500000 MHz (800 mm x 335 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 33 Vpol N
DTD 3: 3440x1440 99.982172 Hz 43:18 150.973 kHz 538.370000 MHz (800 mm x 335 mm)
Hfront 14 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 10 Vback 57 Vpol N
DTD 4: 2560x1080 59.999534 Hz 64:27 66.659 kHz 185.580000 MHz (800 mm x 335 mm)
Hfront 64 Hsync 64 Hback 96 Hpol P
Vfront 3 Vsync 10 Vback 18 Vpol N
DTD 5: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz (800 mm x 335 mm)
Hfront 88 Hsync 44 Hback 148 Hpol P
Vfront 4 Vsync 5 Vback 36 Vpol P
Checksum: 0x76 Unused space in Extension Block: 32 bytes
----------------
Block 2, DisplayID Extension Block:
Version: 1.2
Extension Count: 0
Display Product Type: Standalone display device
Video Timing Modes Type 1 - Detailed Timings Data Block:
DTD: 3440x1440 120.000000 Hz 64:27 183.000 kHz 666.120000 MHz (aspect 64:27, no 3D stereo)
Hfront 48 Hsync 32 Hback 120 Hpol P
Vfront 3 Vsync 10 Vback 72 Vpol N
Checksum: 0x08
Checksum: 0x90
=================
/sys/class/drm/card1-HDMI-A-1
EDID of '/sys/class/drm/card1-HDMI-A-1/edid' was empty.
=================Last edited by reedacartwright (2026-08-13 02:43:39)
Offline
Made in: week 9 of 2026
Was this also a problem w/ your old monitor?
Display supports continuous frequencies
Did you enable https://wiki.archlinux.org/title/Variab … rate#GNOME ?
DTD 1: 3440x1440 59.972616 Hz 43:18 88.819 kHz 319.750000 MHz (800 mm x 335 mm)
DTD 3: 3440x1440 99.982172 Hz 43:18 150.973 kHz 538.370000 MHz (800 mm x 335 mm)
DTD: 3440x1440 120.000000 Hz 64:27 183.000 kHz 666.120000 MHz (aspect 64:27, no 3D stereo)
Are you running the output at 60, 100 or 120 Hz?
The idea would be to run this w/ 60Hz and w/o VRR to keep the pressure off the connection and see whether that avoids the race condition in the driver.
Is there a difference in the suspend triggers between the succeeding and failing ones (notably explicit vs implicit and screenlockers involved)?
Offline
Was this also a problem w/ your old monitor?
It's a new system, built a couple months ago. This has been an issue since day 1.
Are you running the output at 60, 100 or 120 Hz?
The idea would be to run this w/ 60Hz and w/o VRR to keep the pressure off the connection and see whether that avoids the race condition in the driver.
I've mostly run it at 120 Hz w/o VRR. I'll put it at 60Hz to see if it is more stable.
Is there a difference in the suspend triggers between the succeeding and failing ones (notably explicit vs implicit and screenlockers involved)?
I nearly always do CTRL-L to lock GNOME when I leave my desk, and it suspends after 15 minutes of inactivity.
Offline