If you’re running a Ryzen 9950X3D on its integrated GPU under Debian 13 and your system randomly locks up with a solid green screen after hours of normal use, here’s what was going on and how it got resolved.

The Symptom

• System runs fine for an extended period (hours of normal desktop use)
• Suddenly the display goes full-screen solid green
• The machine is completely unresponsive — no recovery, requires a hard reboot
• No obvious pattern at first (not tied to a specific app launch, sleep/wake, etc.)

Variant: the crash doesn’t always show the green screen. Sometimes it’s a silent hard lock instead — the last frame stays frozen on screen, the mouse doesn’t move, and there’s no response to input at all, with no color change. This isn’t a separate bug; it’s the same underlying driver crash surfacing differently depending on exactly where in the display pipeline the hang occurs. A green screen usually means the display pipeline crashed and left a garbage framebuffer; a silent freeze usually means the GPU hung (ring timeout) mid-frame, or the hang propagated further into the kernel before anything visual changed.

The Setup

• CPU: AMD Ryzen 9 9950X3D
• GPU: Integrated graphics (RDNA 3.5 “Radeon Graphics”), using the amdgpu kernel driver
• OS: Debian 13 (“Trixie”), fully updated, kernel 6.12
• Browser: Google Chrome

Diagnosis

A solid-color full-screen freeze like this is a classic signature of a GPU driver crash/hang, as opposed to a kernel panic (which usually leaves partial text or garbled output rather than a clean solid color).

The 9950X3D’s iGPU is new enough in the market that kernel and Mesa driver support is still maturing. Sustained GPU-heavy workloads — particularly hardware-accelerated video decode, canvas rendering, and GPU compositing in Chrome — are known to expose amdgpu driver bugs on newer hardware that lighter desktop usage doesn’t trigger.

Useful diagnostic commands for anyone chasing a similar issue:

# Confirm kernel version
uname -r

# Check for GPU hang/reset errors from the previous boot
journalctl -b -1 -p err -e

Look specifically for amdgpu: log lines mentioning things like page fault, ring gfx timeout, GPU reset, or IH ring — these confirm the crash is coming from the graphics driver.

It’s also worth testing whether SSH still works into the machine when the green screen occurs — if it does, only the display/compositor stack has hung, not the whole kernel.

The Fix

Adjusting Chrome’s hardware graphics acceleration settings (chrome://settings → System → “Use graphics acceleration when available”, or the related flags under chrome://flags) resolved the crashes. Since making that change, no further green-screen lockups have occurred.

Why This Worked

Chrome’s GPU compositing and hardware video acceleration put sustained, heavy load on the GPU in a way typical desktop usage doesn’t. On mature GPU/driver combinations this is usually fine, but on newer hardware like the 9950X3D iGPU, it was enough to expose an underlying amdgpu/Mesa driver bug.

Important caveat: this is a workaround, not a root-cause fix. The underlying driver immaturity is still there. If you:

• Re-enable Chrome’s GPU acceleration,
• Update Chrome to a version that changes its GPU behavior, or
• Run other GPU-intensive workloads (video editing, another browser, gaming),

…the same type of crash could resurface until upstream kernel and Mesa support for this iGPU matures further.

Takeaways

• A full-screen solid-color freeze on Linux usually points to a GPU driver crash, not a kernel panic.
• New AMD hardware (like the 9950X3D) can outpace mainline kernel/Mesa driver support — expect some rough edges for the first several months.
• Chrome’s GPU acceleration is a common trigger for exposing these bugs.
• Keep an eye on journalctl -b -1 -p err after any future crash to catch recurrence early.