RX 9070 XT — Dual monitor DisplayPort signal drops at high refresh rates (Wayland)

Bwisepic28 · May 19, 2026, 6:05am

I’m relatively new to Linux, I’ve been using it on my laptop since December and haven’t had any major issues, so I decided to switch more of my devices over. I finally moved my gaming desktop off Windows 11 and this has been my first real issue. I used AI to try to help me figure out what the problem was and how to fix it and there is still no permanent fix that I have seen without significant tradeoffs.

What I’m asking:

Has anyone else with an RX 9070 XT hit this dual-monitor DisplayPort signal drop issue?
Is there a better fix than forcing the GPU to high power state (which costs ~30W of extra idle power draw)?
Is this a known bug that’s being worked on upstream, or should I file it with the amdgpu maintainers?

Hardware

GPU: PowerColor Hellhound Radeon RX 9070 XT 16GB
CPU: Ryzen 7 9800X3D
Motherboard: Gigabyte X870 Eagle WiFi7
RAM: 32GB DDR5-6000MT/s
PSU: Corsair RM1000e

Monitors

Primary: Samsung Odyssey G70NC (4K 144hz, DisplayPort) — affected
Secondary: Acer K273E (1080p 100hz, HDMI) — never affected

Both monitors connected directly to the RX 9070 XT.

Software

Distro: CachyOS (also reproduced on Fedora 44 KDE)
Kernel: 7.0.9-1-cachyos (also occurred on 7.0.8)
Mesa: 26.1.0-arch2.1
DE: KDE Plasma 6.6.5 on Wayland

Issue

When both monitors are connected and running at high refresh rates, the Samsung randomly loses DisplayPort signal for ~1 second every few minutes. Audio output through the monitor also cuts during these drops, confirming a full DP connection reset rather than just a visual glitch. No errors related to the flicker events have been identified in the kernel log so far.

The secondary Acer over HDMI remains completely stable throughout never drops signal, never flickers, regardless of refresh rate combination. This makes it specifically a Samsung-over-DisplayPort issue, not a general dual-monitor handling issue.

Reproduction

Always happens with Samsung at 144hz + Acer at 100hz
Occurs at various combinations of high refresh rates
Completely stable with both monitors at 60hz
Completely stable with single monitor at any refresh rate

My Hypothesis

Aggressive memory clock (mclk) step-down during idle power-saving states causes a momentary DisplayPort link failure on the Samsung. This is compounded by a Display Core (DCN 4.0.1) buffer calculation bug. Forcing the GPU into the ‘high’ power profile completely eliminates the flickering.

Workaround Summary

Workaround	Result	Tradeoff
Both monitors at 60hz	Fully stable	No high refresh on either monitor
Force GPU to high power state	Stops idle desktop flickers	45-55W idle power (vs 15-30W normal)
Disable iGPU in BIOS	Reduces frequency	Can’t use integrated GPU as a diagnostic fallback if the dGPU fails

Command I used to force GPU into high power:

echo “high” | sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level

Ruled Out

Cable — same cable works fine on Windows 11
DP port — multiple GPU DP ports tested, all behave the same
Monitor — firmware up to date, fully stable on Windows 11
PSU — Corsair RM1000e, PCIe cables are good
Distro — reproduced on Fedora 44 KDE and CachyOS
iGPU interaction — still occurs with iGPU disabled in BIOS
FreeSync/VRR — disabled in OS and Samsung OSD
Kernel version — occurs on both 7.0.8 and 7.0.9-1-cachyos
HDR — disabled, no change
Kernel parameters that didn’t help (tested on Fedora only, not retested on CachyOS):
- amdgpu.runpm=0 via /etc/modprobe.d/amdgpu.conf
- amdgpu.freesync_video=0
- KWIN_DRM_NO_DIRECT_SCANOUT=1 in /etc/environment

Notable Observations to me

Does not occur on Windows 11 with the same hardware
CRB Config Warning: DET size (17,0,4,0) + Compbuf size (1) > CRB segments (21) appears at boot on the 9070 XT (DCN 4.0.1) regardless of iGPU state. Unclear if this is directly related to the signal drops, but it’s the only persistent warning the driver produces.
No kernel errors appear during the actual flicker events themselves
Tried X11 session on Fedora 44 — F44 ships plasmalogin (Wayland-only) instead of SDDM, which prevented X11 from launching properly. Could not test X11 as alternative.

Detailed Testing Notes

1. Hardware Isolation (Integrated Graphics Bypass)

Action: I Disabled the CPU’s integrated Radeon Graphics via motherboard BIOS (dGPU Only Mode = Enabled). Confirmed with lspci -k that only the discrete Navi 48 RX 9070 XT is initialized.

Result: Greatly improved macro-stability during heavy GPU loads (gaming), but did not completely eliminate the issue. System still experiences random ~1 second signal loss during low-load desktop use (browsing, chatting).

Telemetry: The CRB Config Warning remains present in dmesg at boot, proving the buffer allocation warning persists independently of the iGPU’s state.

2. Dynamic Power Management Isolation

Action: Manually forced the GPU out of ‘auto’ power gating:

echo "high" | sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level

Result: Completely stops the intermittent black screen drops during idle desktop use. Dual-monitor layout becomes fully stable.

Tradeoff: Forcing high power state prevents memory clock step-down. GPU idles at ~45-55W instead of normal 15-25W idle.

3. Kernel Lifecycle Testing

Action: Applied latest CachyOS rolling updates, bringing kernel to 7.0.9-1-cachyos.

Result: Tested on stock power settings. Macro-frequency of drops slightly mitigated vs previous kernel baselines, but a definitive signal drop still occurs consistently during the desktop environment initialization loop right at boot-up.

Telemetry: dmesg explicitly logs the buffer conflict at the ~10.6-second handshake mark as the Display Manager spawns the KDE Plasma Wayland session:

[   10.689016] amdgpu 0000:03:00.0: [drm] CRB Config Warning: DET size (17,0,4,0) + Compbuf size (1) >  CRB segments (21)

Diagnostic Information

Commands used:

uname -r
glxinfo | grep "OpenGL"
lspci -k | grep -EA3 'VGA|Display'
sudo journalctl -b -k | grep -iE "amdgpu|drm" | tail -50

Kernel:

uname -r
7.0.9-1-cachyos

OpenGL / Mesa:

glxinfo | grep "OpenGL"
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 9070 XT (radeonsi, gfx1201, ACO, DRM 3.64, 7.0.9-1-cachyos)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 26.1.0-arch2.1
OpenGL version string: 4.6 (Compatibility Profile) Mesa 26.1.0-arch2.1
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 26.1.0-arch2.1

GPU detection (iGPU disabled, only dGPU active):

lspci -k | grep -EA3 'VGA|Display'
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 48 [Radeon RX 9070/9070 XT/9070 GRE] (rev c0)
    Subsystem: Tul Corporation / PowerColor Radeon RX 9070 XT 16GB
    Kernel driver in use: amdgpu
    Kernel modules: amdgpu

Kernel log (amdgpu/drm boot messages):

sudo journalctl -b -k | grep -iE "amdgpu|drm" | tail -50
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: SRAM ECC is not presented.
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: VRAM: 16304M 0x0000008000000000 - 0x00000083FAFFFFFF (16304M used)
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: GART: 512M 0x0000000000000000 - 0x000000001FFFFFFF
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] Detected VRAM RAM=16304M, BAR=16384M
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] RAM width 256bits GDDR6
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0:  16304M of VRAM memory ready
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0:  15845M of GTT memory ready.
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] GART: num cpu pages 131072, num gpu pages 131072
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] PCIE GART of 512M enabled (table at 0x00000083DAB00000).
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] Loading DMUB firmware via PSP: version=0x0A003500
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [VCN instance 0] Found VCN firmware Version ENC: 1.12 DEC: 9 VEP: 0 Revision: 15
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: MES: vmid_mask_mmhub 0x0000ff00, vmid_mask_gfxhub 0x0000ff00
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: MES: gfx_hqd_mask 0x000000fe, compute_hqd_mask 0x0000000c, sdma_hqd_mask 0x000000fc
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: RAP: optional rap ta ucode is not available
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: SECUREDISPLAY: optional securedisplay ta ucode is not available
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: smu driver if version = 0x0000002e, smu fw if version = 0x00000033, smu fw program = 0, smu fw version = 0x00684c00 (104.76.0)
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: SMU is initialized successfully!
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] Display Core v3.2.369 initialized on DCN 4.0.1
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] DP-HDMI FRL PCON supported
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] DMUB hardware initialized: version=0x0A003500
May 18 23:26:15 cachyos kernel: amdgpu 0000:03:00.0: [drm] DP-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: [drm] DP-2: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: [drm] DP-3: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: [drm] HDMI-A-1: PSR support 0, DC PSR ver -1, sink PSR ver 0 DPCD caps 0x0 su_y_granularity 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: program CP_MES_CNTL : 0x4000000
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: program CP_MES_CNTL : 0xc000000
May 18 23:26:16 cachyos kernel: amdgpu: Virtual CRAT table created for GPU
May 18 23:26:16 cachyos kernel: amdgpu: Topology: Add GPU node [0x1002:0x7550]
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: SE 4, SH per SE 2, CU per SH 8, active_cu_number 64
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring sdma0 uses VM inv eng 9 on hub 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring sdma1 uses VM inv eng 10 on hub 0
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring vcn_unified_0 uses VM inv eng 0 on hub 8
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: ring jpeg_dec uses VM inv eng 1 on hub 8
May 18 23:26:16 cachyos kernel: amdgpu: HMM registered 16304MB device memory
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: Using BACO for runtime pm
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: [drm] Registered 4 planes with drm panic
May 18 23:26:16 cachyos kernel: [drm] Initialized amdgpu 3.64.0 for 0000:03:00.0 on minor 1
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: [drm] Failed to setup vendor infoframe on connector HDMI-A-1: -22
May 18 23:26:16 cachyos kernel: fbcon: amdgpudrmfb (fb0) is primary device
May 18 23:26:16 cachyos kernel: amdgpu 0000:03:00.0: [drm] fb0: amdgpudrmfb frame buffer device
May 18 23:26:17 Netsphere systemd[1]: Load Kernel Module drm skipped, unmet condition check ConditionKernelModuleLoaded=!drm
May 18 23:26:18 Netsphere kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
May 18 23:26:18 Netsphere kernel: snd_hda_intel 0000:03:00.1: bound 0000:03:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])
May 18 23:26:20 Netsphere kernel: amdgpu 0000:03:00.0: [drm] CRB Config Warning: DET size (17,0,4,0) + Compbuf size (1) >  CRB segments (21)

Let me know if I need to clarify anything and if more information is needed.

mafdk · May 19, 2026, 9:43am

Half year ago I bought RX9070 (non-XT) and had the same issue with it. I changed displayport cable, bought new PSU and the same issue. I returned to my old 3060Ti and everything worked fine. I tried to resolve the issue and spent hours searching the Internet but nothing helped so I gave up and returned everything I bought to shop.

This problem exists in AMD drivers for really long time but they don’t care. The only solution that I found was lowering the refresh rate. It really sucks.

Bwisepic28 · May 19, 2026, 5:34pm

That really sucks, thanks for your response. Good to know it’s not just my specific card or setup. I’ll file a bug report on AMD’s GitLab and update this thread if I do get an update.

Bwisepic28 · May 20, 2026, 2:17am

Update — Workaround found:

After more research and helpful pointers from the AMD GitLab tracker, this issue is confirmed to be related to #4753 — a known MCLK reclocking bug affecting DCN4/RDNA4 (9000 series) cards. The driver can’t always find a suitable vblank period to change memory clocks in certain multi-monitor / high-refresh configurations, which causes either stuttering or full DisplayPort signal loss depending on the setup.

Fix: Installed LACT and configured it to force the GPU into the highest power state on boot. This prevents MCLK from stepping down and completely eliminates the signal drops. Tradeoff is higher idle power draw (~45-55W vs 15-25W) but on a desktop it’s a fair trade.

Hopefully this gets a proper upstream fix eventually, but until then LACT is a clean solution.

Fran · July 1, 2026, 8:11pm

Hello! I’ve moved into CachyOS recently and I’ve had this same exact issue and found a simple solution, which I hope works for you as well (in case it’s still happening):
I installed LACT, then enabled the Overclocking option (so I can change stuff) and then, in the Overclocking menu, set “Performance Level” as “Manual” and then just changes the “Power States” by un-ticking the VRAM option “0: 192 Mhz”.

I have a 9070XT with 7.1.2-3-cachyos kernel and I hope this helps!

Kahana82 · July 1, 2026, 9:14pm

… in the Overclocking menu, set “Performance Level” as “Manual” and then just changes the “Power States” by un-ticking the VRAM option “0: 192 Mhz”.

I don’t know if it is related to the same issue, but this reduces stutter/slowdowns of menus/interfaces in games (like Overwatch) where it goes into a low frame-rate (30/60) mode, which leads to the GPU clocking the memory down too low, because not much is happening … until you interact with it.