[drm] flip_done timed out — recurring freeze + artifacting on RX 9070 XT (gfx1201), 500Hz HDR over DisplayPort

Ask Fedora
, ,
1

https://paste.centos.org/view/fcf10f33

amdgpu display lockup: [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out

Summary

Recurring hard system freeze on a Fedora Linux workstation with a discrete AMD GPU (also driving the display). The GPU is very recent RDNA4-class silicon (GFX12). Freezes require a hard power cycle to recover from. Root cause not yet identified despite ruling out several plausible causes (below).

System

  • OS: Fedora Linux, kernel 7.1.7-200.fc44.x86_64
  • CPU: AMD Ryzen 7 7800X3D (includes integrated Raphael/RDNA2 graphics, PCI 0000:12:00.0, currently unused for display)
  • Discrete GPU: AMD Radeon, PCI 0000:03:00.0
    • PCI Device ID: 1002:7550
    • VBIOS: 113-APM7604SL-104, build 00146011, ver 023.008.000.068.000001, dated 2025/04/01
    • VRAM: 16304M GDDR6, 256-bit
    • IP blocks report gfx_v12_0 (GFX12 / RDNA4-class architecture)
  • RAM: 32GB DDR5 @ 6000MT/s (dual channel, EXPO enabled)
  • Display: connected via HDMI only, monitor is a 500Hz HDR panel
  • Kernel boot params (current, after fixes below): amdgpu.runpm=0 amdgpu.ppfeaturemask=0xfff7bfff
  • Fully up to date: dnf check-update kernel* linux-firmware reports no updates available

Symptom

GPU/display hard-locks under normal desktop use. Recovery requires a hard power cycle (SSH sessions also become unresponsive, ruling out a simple compositor crash recoverable without reboot). Each incident logs exactly one line before the freeze:

amdgpu 0000:03:00.0: [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out

No corresponding Out of memory: Killed process or other OOM-killer messages in any of the crash logs. No corresponding “Not enough memory for command submission” message except in the very first incident (see Timeline, Incident 1).

Timeline of incidents

# Elapsed time before crash Workload at time of crash Config in effect
1 ~14 min into a model load Ollama loading a 27B model (qwen3.6:27b, ~17GB) via ROCm ppfeaturemask=0xffffffff (default install config)
2 ~32 min Ollama running a 9B model (Qwen3.5-DeltaCoder-9B, ~6.4GB) via ROCm, active chat session ppfeaturemask=0xffffffff
3 ~16 min Same 9B model, active chat session, larger context window (num_ctx 16384, ~7GB) ppfeaturemask=0xffffffff removed entirely (back to compiled-in default 0xfff7ffff, which itself still reports Overdrive enabled)
4 ~4.5 min qwen3.5:9b, active chat session ppfeaturemask=0xfff7bfff (Overdrive bit explicitly cleared from the default)
5 ~10 min No model running. Only action taken was running rocminfo, which itself failed instantly with libhsa-runtime64.so.1: cannot open shared object file (ROCm runtime library missing/broken) before any GPU query could occur ppfeaturemask=0xfff7bfff

Incident 1 additionally logged, just before the freeze:

amdgpu 0000:03:00.0: [drm] *ERROR* Not enough memory for command submission!
amdgpu 0000:03:00.0: VM memory stats for proc ptyxis(7233) task ptyxis(7233) is non-zero when fini
amdgpu 0000:03:00.0: VM memory stats for proc RDD Process(9146) task browser 4 :cs0(8047) is non-zero when fini
amdgpu 0000:03:00.0: VM memory stats for proc firefox(7882) task firefox:cs0(7802) is non-zero when fini
amdgpu 0000:03:00.0: VM memory stats for proc gnome-shell(5751) task gnome-shel:cs0(5709) is non-zero when fini

This looks like genuine VRAM exhaustion (17GB model vs 16GB card, no headroom left for the compositor). Incidents 2-5 do not show this message and involve models that fit comfortably within VRAM (6-7GB used of 16GB total, confirmed via rocm-smi showing ~39-42% usage, flat/stable, no leak), which is why VRAM exhaustion has been ruled out as the explanation for incidents 2-5.

What’s been ruled out

  • Model size / VRAM exhaustion — incident 1 fits this, but incidents 2-5 do not. Crashes continued at ~6-7GB VRAM usage on a 16GB card.
  • Overdrive / unstable PowerPlay feature mask — the machine was originally booting with amdgpu.ppfeaturemask=0xffffffff (all 32 feature bits enabled, including Overdrive), which the driver itself warns against (“Overdrive is enabled, please disable it before reporting any bugs unrelated to overdrive”). This was removed entirely, then the Overdrive bit (0x4000) was explicitly cleared from the compiled-in default (0xfff7ffff → 0xfff7bfff), confirmed via cat /sys/module/amdgpu/parameters/ppfeaturemask and confirmed the driver’s Overdrive warning no longer appears in dmesg. Crash recurred anyway (incident 4).
  • Stale kernel/firmware — dnf check-update kernel* linux-firmware reports fully up to date at time of writing.
  • Sustained AI compute load specifically — incident 5 occurred with no model loaded and no successful ROCm call (the only ROCm-touching command run, rocminfo, failed instantly on a missing shared library, before it could have queried or engaged the GPU).
  • General (non-GPU-compute-related) instability — per the user, the machine has never frozen or shown display glitches during normal use when no Ollama/local-model activity is anywhere in the picture (browsing, terminal work, etc.), which is why suspicion centered on Ollama/ROCm activity in the first place — though incident 5 now complicates that a bit.

Separately noticed, possibly unrelated

rocminfo fails outright:

rocminfo: error while loading shared libraries: libhsa-runtime64.so.1: cannot open shared object file: No such file or directory

This suggests the system-level ROCm install is incomplete or broken, independent of whatever Ollama uses internally (Ollama has its own bundled HIP/ROCm libraries and was successfully running models via GPU offload, confirmed via rocm-smi showing GPU VRAM usage climb and hold during inference). Not yet determined whether this is connected to the freezes.

Hardware/software notes potentially relevant to RDNA4

  • GPU IP blocks (gfx_v12_0, PCI ID 1002:7550) place this in the RDNA4/GFX12 generation, which is very recent (VBIOS dated April 2025).
  • ROCm only added native support for RDNA4 (gfx1200/gfx1201) in version 7.2 (March 2026) — prior to that, RDNA4 required a manual HSA_OVERRIDE_GFX_VERSION compatibility hack.
  • There is at least one open upstream report of RDNA4 (gfx1201)-specific instability under HIP/ROCm compute workloads (GPU entering a permanent non-idle/hung state), described as a HIP queue initialization/teardown issue specific to this architecture (ROCm/ROCm#5706).
  • System-installed ROCm version has not yet been confirmed (blocked by the missing libhsa-runtime64.so.1 library preventing rocminfo from running) — worth checking whether it predates 7.2, though incident 5 (crash with no successful ROCm call at all) suggests this may not be the whole story.

What would help

  • Confirmation of whether this matches a known amdgpu/RDNA4 display-pipeline bug.
  • Guidance on whether [CRTC:424:crtc-0] flip_done timed out in isolation (no preceding OOM or memory-submission error) points to a specific subsystem (DC/DCN display core, PSP/SMU firmware, or something else).
  • Whether routing display output through a secondary GPU (this system has an unused iGPU, PCI 0000:12:00.0, currently with no display attached) is a reasonable/known workaround for this class of bug, or whether the freezes would be expected to persist regardless of what’s driving the display.
3

“Also noticed intermittent pixelation specifically during window zoom/resize animations, which may be a lower-severity version of the same instability.”

4

Update — crash occurred with GPU compute completely idle; likely display-pipeline related, not compute-related

Following up with new information that significantly changes the picture from my original report.

Hardware clarification: the GPU is an AMD Radeon RX 9070 XT (gfx1201, RDNA4), PCI 0000:03:00.0. It drives a 500Hz HDR monitor over DisplayPort (not HDMI as I originally noted — correcting that).

Key new finding: one freeze occurred with no GPU compute activity at all.

My original report attributed the freezes to local LLM inference (Ollama/ROCm), since that’s when I first noticed them. Checking Ollama’s own service log against the kernel log for one incident shows that assumption was wrong:

  • Ollama’s log shows only routine idle GET /v1/models API polling (once per minute) right up to the second of the crash
  • No model was loaded, and no inference was running
  • The kernel logged [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out at that exact timestamp

So the compute path was idle when the freeze occurred. That points away from ROCm/HIP compute as the trigger and toward the display pipeline itself.

What Ollama reports about GPU detection (for completeness, since I originally suspected a ROCm support gap):

level=INFO source=types.go:32 msg="inference compute" id=0 filter_id=0 library=ROCm
  compute=gfx1201 name=ROCm0 description="AMD Radeon RX 9070 XT"
  libdirs=ollama,rocm_v7_2 driver=0.0 pci_id=0000:03:00.0 type=discrete
  total="15.9 GiB" available="15.8 GiB"

Ollama 0.30.10 bundles rocm_v7_2, which has native gfx1201 support, and detection is clean. So an outdated/missing RDNA4 ROCm path is not the explanation. (Separately, the system-level rocminfo is broken — libhsa-runtime64.so.1: cannot open shared object file — but Ollama ships its own ROCm libraries and doesn’t depend on it, so this appears unrelated.)

HDR is actively engaged. The kernel log shows HDR metadata being transmitted shortly before one of the freezes:

kernel: HDR SB:01 1a 02 00 48 8a 08 39 34 21 aa 9b 96 19 fc 08
kernel: HDR SB:13 3d 42 40 10 27 32 00 00 00 00 00 00 00 00 00

Additional symptom not in the original report: intermittent visible screen pixelation/artifacting, occurring specifically during window zoom/resize animations. This may be a lower-severity manifestation of the same underlying instability — it suggests the display/compositing path rather than compute.

Revised summary of what’s been ruled out:

  • Model size / VRAM exhaustion — crashes continued with ~6-7GB used of 16GB
  • Overdrive / PowerPlay feature mask — ppfeaturemask explicitly set to 0xfff7bfff (Overdrive bit cleared), confirmed via sysfs and confirmed the driver’s Overdrive warning no longer appears; crash recurred anyway
  • Outdated kernel/firmware — fully up to date (7.1.7-200.fc44.x86_64)
  • ROCm RDNA4 support gap — Ollama bundles rocm_v7_2 with native gfx1201 support
  • GPU compute activity as the trigger — one freeze occurred with Ollama completely idle
  • HDMI 2.1 / FRL limitations — display is connected via DisplayPort, not HDMI

Current working hypothesis: something in the display pipeline (DCN) is timing out under a high-bandwidth mode — 500Hz refresh combined with HDR on RDNA4. The flip_done timed out error is consistent with a frame flip not completing in time, and the zoom/resize pixelation points the same direction.

Questions:

  1. Are there known flip_done timed out issues on RDNA4 (gfx1201) at very high refresh rates and/or with HDR enabled over DisplayPort?
  2. Is there any diagnostic output that would be more useful than what I’ve provided — e.g. drm.debug output at a particular level, or DC/DCN-specific logging — that I could capture on the next occurrence?
  3. Would testing at a reduced refresh rate and/or with HDR disabled be a useful data point to report back, and if so is there a particular threshold worth testing at?

I’m planning to test lower refresh rates and HDR-disabled as separate variables and will report results.

5

Second update — artifacting occurs at near-idle GPU load; thermals ruled out

Further to my previous update, I’ve now checked thermals and load levels, which rules out a couple of things and makes one earlier observation more significant rather than less.

Thermals are not the issue.

Sensor readings taken while a game was actively running (Minecraft Bedrock via mcpelauncher):

amdgpu-pci-0300
Adapter: PCI adapter
vddgfx:      715.00 mV
fan1:           0 RPM  (min =    0 RPM, max = 3600 RPM)
edge:         +53.0°C  (crit = +110.0°C, hyst = -273.1°C)
                       (emerg = +115.0°C)
junction:     +57.0°C  (crit = +110.0°C, hyst = -273.1°C)
                       (emerg = +115.0°C)
mem:          +76.0°C  (crit = +108.0°C, hyst = -273.1°C)
                       (emerg = +113.0°C)
PPT:          57.00 W  (cap = 304.00 W)

Everything is far below any thermal threshold, and the card is drawing only 57W of a 304W cap with fans still in zero-RPM mode. Case airflow includes three intake fans directly below the GPU.

Important consequence: the GPU is effectively idle during the workloads where I see artifacting.

Minecraft Bedrock is a very light renderer and does not meaningfully load this card — the sensor readings above were taken mid-game and are essentially indistinguishable from idle. So the visible pixelation/artifacting I reported is occurring at near-idle GPU load, not under stress. The same applies to the artifacting during window zoom/resize animations.

This makes the artifacting more notable rather than less: visual corruption on an essentially idle GPU is harder to attribute to load, thermals, or power delivery.

One anomaly worth flagging: the memory temperature reads +76.0°C while the core sits at +53.0°C — a ~23°C gap — and this reading is identical at idle and during light gaming (it did not move at all between the two states). Well below the 108°C critical threshold, so not dangerous, but the constant value across load states seems unusual and I’m unsure whether it’s a genuine reading or a sensor reporting quirk on this card.

Revised picture:

  • Artifacting is reproducible across completely unrelated workloads (a game with no compute/ROCm involvement, and GNOME window animations)
  • It occurs at near-idle GPU load
  • Thermals, cooling, and power draw are all well within normal range
  • The system ran a ~16 hour gaming session the previous day without freezing — though given the load figures above, that session was not the sustained GPU stress test I initially took it for

Additional question, on top of those in my previous update:

  1. Given that artifacting reproduces during pure graphics workloads at near-idle load, with no ROCm/compute involvement and no thermal pressure — does this suggest a specific area of the graphics/display path worth investigating, or would this pattern be more consistent with marginal hardware? I’d like to know whether it’s worth pursuing an RMA conversation with the vendor in parallel, or whether this is a known software-side issue on RDNA4.
6

Third update — ROCm/compute definitively ruled out; freeze reproduces with GPU compute fully disabled

This update supersedes the framing of my original report. The freezes are not related to GPU compute, ROCm, or local LLM inference. Please disregard that angle entirely.

The test: I disabled Ollama’s GPU backend completely by forcing CPU-only inference, via a systemd override:

[Service]
Environment="OLLAMA_LLM_LIBRARY=cpu"

Confirmed in Ollama’s startup log that the GPU was not being used for inference at all:

level=INFO source=types.go:50 msg="inference compute" id=cpu library=cpu compute=""
  name=cpu description=cpu libdirs=ollama driver="" pci_id="" type=""
  total="30.2 GiB" available="19.1 GiB"
level=INFO source=routes.go:2031 msg="vram-based default context" total_vram="0 B" default_num_ctx=4096

Note library=cpu and total_vram="0 B" — the ROCm device was not enumerated for inference at all, unlike previous boots which showed library=ROCm compute=gfx1201.

Result: the system froze anyway, with the same [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out signature.

What this definitively rules out:

  • ROCm / HIP runtime as the trigger
  • RDNA4 (gfx1201) compute support gaps
  • Model size, VRAM exhaustion, GPU memory pressure, GPU offload behaviour
  • Local LLM inference in general

Consolidated list of everything now ruled out across all updates:

Suspected cause Status
Model size / VRAM exhaustion Ruled out — crashes at ~6-7GB used of 16GB
Overdrive / PowerPlay feature mask Ruled out — ppfeaturemask=0xfff7bfff, Overdrive bit cleared, driver warning gone, crash recurred
LACT overclock/undervolt profile Ruled out — config contained no OC/UV profile (current_profile: null), daemon was dead (exit 127) and had not run
Outdated kernel / firmware Ruled out — fully up to date (7.1.7-200.fc44.x86_64)
ROCm RDNA4 support gap Ruled out — Ollama bundles rocm_v7_2 with native gfx1201 support, detection clean
Thermals / cooling / power delivery Ruled out — 53°C core, 57°C junction, 57W of a 304W cap during the workload, well within limits
GPU compute activity Ruled out — freeze reproduces with GPU compute fully disabled (this update), and one freeze occurred with Ollama completely idle (previous update)
HDMI 2.1 / FRL bandwidth limits Not applicable — display is DisplayPort

What remains, and what the evidence points to:

  • Every freeze logs [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out and nothing else
  • Visible pixelation/artifacting occurs during pure graphics workloads (a game, GNOME window zoom/resize animations) with zero compute involvement
  • Artifacting occurs at near-idle GPU load with clean thermals
  • Hardware: AMD Radeon RX 9070 XT (gfx1201, RDNA4), PCI 0000:03:00.0, driving a 500Hz HDR monitor over DisplayPort
  • HDR is actively engaged (HDR SB: metadata lines appear in the kernel log)
  • System also has an unused iGPU (Raphael, PCI 0000:12:00.0) with no display attached

This now looks like a display-pipeline (DCN) issue rather than anything compute-related — a frame flip not completing, on a high-bandwidth display mode, on recent RDNA4 silicon.

Updated questions:

  1. Are there known flip_done timed out issues on RDNA4 (gfx1201) at very high refresh rates and/or with HDR enabled over DisplayPort?
  2. Is there more useful diagnostic output I could capture on the next occurrence — drm.debug at a specific level, or DC/DCN-specific logging?
  3. Would testing at a reduced refresh rate and/or with HDR disabled be a useful data point, and is there a particular threshold worth testing at?
  4. Given that artifacting reproduces during pure graphics workloads at near-idle load with clean thermals, does this pattern suggest a specific area of the display path worth investigating — or is it more consistent with marginal hardware? I’d like to know whether an RMA conversation with the vendor is worth pursuing in parallel.

Apologies for the misleading original framing — the AI/compute correlation was coincidental, since those sessions simply happened to be when I was using the machine for long enough stretches to notice.

8

Fourth update — IMPORTANT CORRECTION: this is a display-output stall, not a system freeze

I need to correct the core symptom description in my original report. The system does not freeze. Only the display output stops updating. The machine continues running normally behind the frozen screen.

I described this as a “freeze” because the screen becomes static and stops responding visually. That description was wrong, and it likely points triage in the wrong direction.

Evidence that the system stays fully alive after the display stalls:

Timeline from a single incident, correlating the kernel log with application logs from the same boot:

15:34:19  kernel: amdgpu 0000:03:00.0: [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out
15:34:52  ollama: slot print_timing: id  0 | task 0 | n_decoded = 1383, tg = 9.80 t/s
15:34:55  ollama: slot print_timing: id  0 | task 0 | n_decoded = 1413, tg = 9.80 t/s
15:34:58  ollama: slot print_timing: id  0 | task 0 | n_decoded = 1443, tg = 9.80 t/s
15:35:01  ollama: slot print_timing: id  0 | task 0 | total time = 150852.91 ms / 1490 tokens
15:35:01  ollama: srv update_slots: all slots are idle
15:35:01  ollama: [GIN] 200 | 2m31s | 127.0.0.1 | POST "/api/chat"
15:35:17  com.docker.backend: >> HEAD /_ping  (routine API polling, still active)

After flip_done timed out at 15:34:19, the system continued running for at least a full minute: an LLM inference job kept generating tokens at a steady 9.80 t/s and completed its response cleanly, and background services carried on polling normally.

Additionally — and independently of the logs — a Minecraft multiplayer session remained connected to a remote server throughout, with the game process still functioning behind the static screen. Networking, CPU, and process scheduling were all unaffected.

Revised symptom description:

  • The display output stops updating (screen goes static / stops refreshing)
  • The system itself continues running normally: processes keep executing, network connections stay alive, disk I/O and logging continue
  • Exactly one kernel message is logged: [drm] *ERROR* [CRTC:424:crtc-0] flip_done timed out
  • I have been hard power-cycling to recover, which was probably unnecessary — I will try VT-switching (Ctrl+Alt+F3 then back) on the next occurrence to see whether the display pipeline recovers without a reboot, and will report the result

This means the correct characterisation is: the compositor requests a page flip, the GPU never signals completion, and display output stalls — while the rest of the system is unaffected. It is a display-pipeline (DCN) stall, not a hang, lockup, or crash.

Hardware/config recap:

  • GPU: AMD Radeon RX 9070 XT (gfx1201, RDNA4), PCI 0000:03:00.0
  • Display: 500Hz HDR monitor over DisplayPort
  • Kernel: 7.1.7-200.fc44.x86_64 (Fedora 44), fully up to date
  • Kernel params: amdgpu.runpm=0 amdgpu.ppfeaturemask=0xfff7bfff
  • HDR is actively engaged (HDR SB: metadata lines present in the kernel log)
  • Unused iGPU present (Raphael, PCI 0000:12:00.0), no display attached

Everything ruled out so far (consolidated across all updates):

Suspected cause Status
Model size / VRAM exhaustion Ruled out
Overdrive / PowerPlay feature mask Ruled out — Overdrive bit cleared, verified via sysfs, symptom recurred
LACT overclock/undervolt profile Ruled out — no OC/UV profile configured, daemon dead (exit 127)
Outdated kernel / firmware Ruled out — fully current
ROCm RDNA4 support gap Ruled out — Ollama bundles rocm_v7_2, native gfx1201 support, clean detection
Thermals / cooling / power delivery Ruled out — 53°C core, 57°C junction, 57W of 304W cap
GPU compute activity Ruled out — reproduces with GPU compute fully disabled (OLLAMA_LLM_LIBRARY=cpu), and once with the compute stack completely idle
HDMI 2.1 / FRL bandwidth Not applicable — DisplayPort
System hang / lockup Ruled out — system demonstrably keeps running (this update)

Related symptom: intermittent visible pixelation/artifacting during window zoom/resize animations and in-game, occurring at near-idle GPU load with clean thermals. Possibly a lower-severity manifestation of the same display-path issue.

Questions, updated for the corrected symptom:

  1. Given that this is a display-output stall with the system otherwise healthy, are there known flip_done timed out issues on RDNA4 (gfx1201) — particularly at very high refresh rates and/or with HDR enabled over DisplayPort?
  2. Is there specific diagnostic output worth capturing on the next occurrence — drm.debug at a particular level, or DC/DCN-specific logging? Since the system stays alive, I should be able to capture logs over SSH while the display is stalled, if that would be useful.
  3. Is VT-switching or a compositor restart the expected recovery path for this condition, or is there a better way to reset the display pipeline without rebooting?
  4. Would testing at reduced refresh rate and/or with HDR disabled be a useful data point, and is there a particular threshold worth testing at?
  5. Does the artifacting at near-idle load with clean thermals suggest a specific area of the display path, or is it more consistent with marginal hardware? I’d like to know whether an RMA conversation with the vendor is worth pursuing in parallel.

Apologies for the two rounds of misleading framing — first attributing this to GPU compute, then describing it as a system freeze. Both turned out to be wrong.

9

There are known issues with the current kernel and AMD 9000 series GPUs, please take a look here: Graphical issues on AMD after kernel update to 7.1.6

10

I have 9070 XT with the same issue as yours on 7.1.6+ kernels
Did 7.1.8 with said fixes to amdgpu solved it for you?

11

So far the best solution has been dropping from 500hz to 240hz. Doesn’t fix the pixelation. Just the screen freeze. Still working on some things.

12

I have had a lot of display freezes with my RX 9070 XT which have suddenly become much more frequent, for an unknown reason. Display freezes are usually fixed by power cycling the monitor.
The (rarer) system freezes have no fix that I’m aware of at this time.

13

So far I’ve been stable with the Hz drop.

14

I tried switching from 240 Hz (my screen’s maximum) to 120 Hz, but unfortunately it doesn’t change anything. I still get random freezing, and can unfreeze by power cycling the monitor.

So once again, it seems that solutions are not universal :-/

15

Fred, does it help if you boot your system with amdgpu.dcdebugmask=0x10 ?

If you test, you might open a new topic when posting your data/results, along with a more detailed elaboration of your context and the symptoms/behaviors incl. logs, because the case of this topic seems to be different than yours. Add the kernel tag if doing so.