615.71.09: screens blink on memory clock changes with three 1440p 180Hz DP monitors

[DanFraserUK]

NVIDIA Open GPU Kernel Modules Version

615.71.09 (CachyOS nvidia-open-dkms 615.71.09-1). Last good version 610.57.04-3.

Please confirm this issue does not happen with the proprietary driver (of the same version). This issue tracker is only for bugs specific to the open kernel driver.

• I confirm that this does not happen with the proprietary driver package.

Operating System and Version

CachyOS (rolling). KDE Plasma 6.7.5, KWin Wayland.

Kernel Release

7.2.6-1-cachyos

Please confirm you are running a stable release kernel (e.g. not a -rc). We do not accept bug reports for unreleased kernels.

• I am running on a stable kernel release.

Hardware: GPU

RTX 5070 Ti

Describe the bug

I run three MSI MAG 274QF monitors at 2560x1440 180Hz. All three are on DisplayPort.

On 615.71.09 the screens blink off for 2 to 3 seconds. It happens when something redraws. Moving the mouse, resizing a window or typing can all set it off. Often a different screen blinks from the one being redrawn. The desktop does not see a disconnect.

Nothing is logged after the driver loads:

$ sudo dmesg | grep -iE 'nvrm|nvidia|drm'
[    4.541139] NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  615.71.09  Release Build
[    4.559069] nvidia-modeset: Loading NVIDIA UNIX Open Kernel Mode Setting Driver for x86_64  615.71.09  Release Build
[    5.468210] [drm] Initialized nvidia-drm 0.0.0 for 0000:01:00.0 on minor 1
[    5.510034] nvidia 0000:01:00.0: [drm] fb0: nvidia-drmdrmfb frame buffer device
[    7.104227] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card0/input15

I watched the memory clock with nvidia-smi. On 615 it moves between P0, P3, P5 and P8. The blinks line up with these changes.

Sampled once a second:

$ nvidia-smi --query-gpu=pstate,clocks.mem --format=csv -l 1
P3, 7001 MHz
P5, 810 MHz
P5, 810 MHz
P8, 405 MHz
P0, 14001 MHz
P3, 14001 MHz
P3, 7001 MHz
...
P0, 14001 MHz
P0, 14001 MHz
P3, 7001 MHz
...
P5, 810 MHz
P8, 405 MHz

Sampled every 100ms, printing only on change:

$ stdbuf -oL nvidia-smi --query-gpu=pstate,clocks.mem --format=csv,noheader -lms 100 | awk '$0!=p{print strftime("%T"), $0; fflush(); p=$0}'
16:16:56 P3, 7001 MHz
16:17:04 P5, 810 MHz
16:17:09 P8, 405 MHz
16:17:10 P5, 810 MHz
16:17:10 P8, 405 MHz
16:17:11 P5, 810 MHz
16:17:11 P8, 405 MHz
16:17:19 P0, 14001 MHz
16:17:21 P3, 7001 MHz
16:17:30 P5, 810 MHz
16:17:34 P8, 405 MHz

In another run the screens kept blinking while I typed. It only logged P3 and P0 changes:

16:13:57 P3, 7001 MHz
16:14:03 P0, 14001 MHz
16:14:04 P3, 7001 MHz
16:14:19 P0, 14001 MHz
16:14:19 P3, 7001 MHz
16:14:35 P0, 14001 MHz
16:14:35 P3, 7001 MHz

I think some switches are too quick for a 100ms sample to catch.

Locking the memory clock to a range did not help. It stopped the drops to P5 and P8 but the screens still blinked:

$ sudo nvidia-smi -lmc 6999,14001
Memory clocks set to "(memClkMin 6999, memClkMax 14001)" for GPU 00000000:01:00.0
All done.

$ nvidia-smi --query-gpu=pstate,clocks.mem --format=csv -l 1
P3, 7001 MHz
P0, 14001 MHz
P3, 7001 MHz
P3, 7001 MHz
P0, 14001 MHz
P3, 7001 MHz

Locking it to max stopped the blinking completely. Running the command caused one blink as it switched. After that nothing blinked:

$ sudo nvidia-smi -lmc 14001,14001

I rolled back to 610.57.04 and the blinking is gone. With no lock set, 610 holds P0 14001 MHz the whole time with this setup:

$ nvidia-smi --query-gpu=driver_version --format=csv
driver_version
610.57.04

$ sudo nvidia-smi -rmc && stdbuf -oL nvidia-smi --query-gpu=pstate,clocks.mem --format=csv,noheader -lms 100 | awk '$0!=p{print strftime("%T"), $0; fflush(); p=$0}'
All done.
16:37:05 P0, 14001 MHz

It never printed another line. So it looks like 615 started allowing memory clock changes here and 610 did not.

I checked the kernel log for the errors in #1361. There were none in any saved boot:

$ journalctl _TRANSPORT=kernel -g 'Flip event timeout|nv_flip'
-- Boot 0fc22a0a5dca4a1b93a4e7a1dc7107c3 --
-- Boot e8a479382ebf41619fa5846b7ae70c29 --
-- Boot 3e843b56356943d3a0c3b88bc6a8f7ed --
-- No entries --

$ journalctl _TRANSPORT=kernel -g 'NVRM: loading'
-- Boot 0fc22a0a5dca4a1b93a4e7a1dc7107c3 --
Sep 23 14:11:37 cachyos kernel: NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  615.71.09  Release Build
-- Boot e8a479382ebf41619fa5846b7ae70c29 --
Sep 23 16:34:58 cachyos kernel: NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  610.57.04  Release Build
-- Boot 3e843b56356943d3a0c3b88bc6a8f7ed --
Sep 23 16:45:50 cachyos kernel: NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  610.57.04  Release Build

The 14:11 boot is a 615 session where the screens blinked. An earlier 615 boot that blinked has rotated out of the journal. The dmesg above is from that boot, and it had no flip timeouts either.

The same monitor on the same port ran at 180Hz on Windows 11 with no blinking. Windows reports 8-bit RGB and VRR support from 49 to 180Hz. On Linux, kscreen reported most of these outputs as VRR "incapable". I don't know if that matters.

Separately, on 615 one DP connector gave no signal with any monitor or cable. The other two connectors worked. This was after a lot of unplugging and cable swapping. The dead output still showed as connected at 180Hz with the right monitor ID. Only brightness control was missing:

Output: 1 DP-2 cb53ef31-61e2-4b0a-9a6f-8f2da787e8f5
        enabled
        connected
        Modes:  1:2560x1440@60.00!  2:2560x1440@180.00*  ...
        Brightness control: unsupported

A reboot fixed it. This looks like #1359 and #1357 rather than something new.

To Reproduce

1. Connect three 2560x1440 180Hz monitors over DisplayPort.
2. Log into KDE Plasma on Wayland with 615.71.09.
3. Move windows around or type for a while.
4. Screens blink.

Bug Incidence

Sometimes

nvidia-bug-report.log.gz

Not attached. I've rolled back to 610. I can reinstall 615 and capture one but I am currently too busy at the time of making this report, not sure how soon I can make one with all the testing and logging required.

More Info

Possibly related: #1359, #1357, #1367, #1371.

[thesword53]

I have the same issue using RTX 2080 SUPER, 2560x1440@360Hz and 2560x1440@144Hz screens. Before the 615 series, the GPU was stuck to the maximum power state (P0). With 615 series a new kernel parameter was added modprobe nvidia "NVreg_RegistryDwords=RmDisableDisplayGlitchPerfLimit=1", to disable this behavior but I have the same issue as you when setting the parameter.

Edit: This issue happens regardless I'm using Wayland, Xorg or even TTY and also affects the Windows driver.

[DanFraserUK]

Oh thank god it's not just me!

I was nearly crying because at one point I thought my GPU was dying.