[BUG] amdgpu: Mode1 resets and Link Training failure on RX 9070XT via KVM

[a-development@posteo.de]

Hello,

I am experiencing a consistent display power-cycling issue with a new 
AMD Radeon RX 9070XT (RDNA 4). I am looking for guidance on whether this 
is a known regression in DCN (Display Core Next) or a specific hardware 
compatibility issue.

Hardware Environment:
- GPU: AMD Radeon RX 9070XT
- Comparison GPU: AMD Radeon W7500 (Works perfectly in the same setup)
- Connection Chain: Multiple DP ports via CableMatters Dongle -> TeSmart 
KVM.
- Direct Port: HDMI-A-1 is connected without a dongle, yet also exhibits 
failures.
- Display: 1920x1080 @ 240Hz (Issue persists even when lowered to 60Hz)

Kernel/Software Environment:
- Distributions: Arch Linux
- Kernels tested: 6.19.11-arch1-1.1 and Mainline 7.0-rc
- Firmware: Tested with latest linux-firmware (up to 2026-04-15)
- Compositors: Sway (constant cycling), Niri (intermittent), SDDM 
(constant)
- Troubleshooting: Tested multiple command-line options including 
pcie_aspm=performance, amdgpu.abmlevel=0.

EDID and Firmware Troubleshooting:
I have attempted to bypass the EDID communication errors by manually 
exporting the EDID and applying it via the 'drm.edid_firmware' 
parameter. This did not resolve the power-cycling, suggesting the 
failure occurs deeper in the link training or DCN power state transition 
rather than just simple metadata acquisition.

Furthermore, the logs indicate a potential SMU issue:
"amdgpu: SMU driver if version not matched"

Description of Behavior:
Upon entering a graphical environment, any mouse movement triggers the 
displays to power off and then back on again. While the 9070XT 
successfully negotiates the 1920x1080 @ 240Hz link initially and can 
render frames, it enters an immediate on-off cycle during active input.

Critically, HDMI-A-1 (which does not use a dongle) also fails to read 
EDID initially, and forced EDID overrides do not stabilize the link. 
This behavior is unique to the 9070XT; the W7500 workstation card 
functions without issue on the exact same cabling setup.

Relevant journalctl output (amdgpu):
amdgpu 0000:03:00.0: [drm] enabling link 0 failed: 15
amdgpu 0000:03:00.0: [drm] enabling link 2 failed: 15
[drm:dm_helpers_read_local_edid [amdgpu]] *ERROR* EDID err: 2, on 
connector: HDMI-A-1
amdgpu 0000:94:00.0: [drm] *ERROR* No EDID read.
amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
amdgpu 0000:03:00.0: amdgpu: MODE1 reset
amdgpu 0000:03:00.0: amdgpu: GPU mode1 reset

Analysis:
Since forced EDID injection fails and the SMU reports a version 
mismatch, I am concerned this is an issue with the SMU/DCN firmware 
interaction on this new architecture or a driver-side link training 
timeout.

Could you provide insight on whether there are specific 'amdgpu' module 
parameters I should use to debug the Display Core (DC) or if I should 
provide a more verbose log with amdgpu.debug_mask?

Thank you for your time and assistance.

Best regards,