Skip to content

5700XT: 20 second delay when display manager is loading ("I'm not done with your previous command")

Brief summary of the problem:

When booting, it takes a relatively long time for the display manager to show up. This happens at each boot, although between restarts the behavior might get slightly better or worse.

I've been having issues with this for almost two years now.

Hardware description:

  • CPU: AMD Ryzen 9 3900X 3.8 GHz
  • GPU: Asus Radeon RX 5700 XT 8GB (I believe it's an early model, bought in October 2019).
  • System Memory: 4x 16 GB Corsair Vengeance LPX 3200 MHz
  • Display(s): Samsung 49" Curved Business Monitor with 32:9 Super Ultra-Wide screen C49J890DK
  • Resolution: 3840x1080 @ 120 Hz
  • Type of Display Connection: Using HDMI mode 2.0.

Result of lspci -nn | grep VGA:

0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] [1002:731f] (rev c1)

System information:

  • Distro name and Version: NixOS 22.11
  • Kernel version: Linux workstation 6.2.6 #1-NixOS SMP PREEMPT_DYNAMIC Mon Mar 13 09:26:43 UTC 2023 x86_64 GNU/Linux
  • Custom kernel: N/A
  • AMD official driver version: N/A

How to reproduce the issue:

The ~20s delay always happens at start-up, when the display manager is supposed to show up. Persistent across reboots, shutdown, etc.

dmesg reveals:

[   42.967803] amdgpu 0000:0b:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x0000000D SMN_C2PMSG_82:0x00000000
[   42.967811] amdgpu 0000:0b:00.0: amdgpu: Failed to retrieve enabled ppfeatures!

Other remarks

  • Actions taken in the past (not much detail, but I could try to reproduce any of them if needed):
    • Tested on DisplayPort back in September 2022 and the graphical target would show up faster, although it is undesireable since it seems to limit frequency to 100 Hz instead of 120 Hz.
    • Tried using a monitor with a smaller resolution and frequency and the issue is not reproducible.
    • Tried using the monitor's picture-in-picture function which reduces the resolution to 1920x1080 => would boot even when it used to crash.
    • In previous kernel versions, the only way to get it running was to use amdgpu.dpm=0. Since kernel 5.15.67, this got broken.
    • Even if amdgpu.dpm=0 would crash since 5.15.67, amdgpu.dpm=0 nomodeset would not crash, but the screen would be too stretched to be usable.
    • The issue is not limited to NixOS, happened on Arch Linux and Elementary OS as well.
    • Tried moving the graphics card to a different PCI Express slot (currently in a x8 slot even though the graphics card is x16) => no change.
    • At some point I had a [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! during runtime which would break KDE. This disappeared after some kernel updates, also set iommu=pt which seemed to improve the situation (not sure if just a coincidence).
  • A timeline of the issues (tested September 2022):
    • 5.15.67
      • DPM off: kernel would panic amdgpu: smu firmware loading failed
      • DPM on: worked initially, after a cold reboot did not work anymore
    • 5.18.19
      • DPM off: kernel would panic amdgpu: smu firmware loading failed
      • DPM on: amdgpu 0000:0b:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000040 SMN_C2PMSG_82:0x00000001
    • 5.19.8
      • DPM off: kernel would panic amdgpu: smu firmware loading failed
      • DPM on: seemed OK, but got a weird issue with snd_hda_intel
    • 5.19.9
      • DPM off: kernel would panic amdgpu: smu firmware loading failed
      • DPM on: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000040 SMN_C2PMSG_82:0x00000001

Attached files: