Skip to content

Instantly share code, notes, and snippets.

@mattbell87
Last active July 21, 2026 23:40
Show Gist options
  • Select an option

  • Save mattbell87/71c78ae717636f4ecf9ce54857641cd4 to your computer and use it in GitHub Desktop.

Select an option

Save mattbell87/71c78ae717636f4ecf9ce54857641cd4 to your computer and use it in GitHub Desktop.
iMac12,1 (21.5" mid-2011) HD6770M — fix graphical glitch/GPU lockup on wake from sleep on Linux (radeon.dpm=0)

iMac12,1 (21.5" mid-2011) — GPU glitch / lockup on wake from sleep (Linux)

Machine: Apple iMac12,1 (21.5", mid-2011) GPU driving the panel: AMD Radeon HD 6770M — "Whistler"/Turks, Northern Islands (TeraScale 2), PCI id 1002:6740 Driver: radeon kernel module (NOT amdgpu — this chip is pre-GCN, so radeon is the only option) OS when diagnosed: Fedora Linux 44 (KDE Plasma), kernel 7.1.4, X11, EFI boot Date fixed: 2026-07-22

Symptom

After waking from suspend, the Plasma desktop shows large black-and-white "stair-step" corruption and never recovers — but switching to a text console (Ctrl+Alt+F2) shows a perfectly clean TTY. Only a reboot restores the desktop.

Root cause

On resume, the GPU's graphics command ring (ring 0 / GFX) locks up. The kernel log shows:

radeon 0000:01:00.0: GPU lockup (... on ring 0)
radeon 0000:01:00.0: GPU softreset: 0x00000019
radeon 0000:01:00.0: GPU reset succeeded, trying to resume
[drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed out.
[drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110).

The TTY works because the console just scans out a framebuffer and never submits GFX commands; the moment the compositor (KWin/Plasma — or any accelerated X/Wayland client) submits to ring 0, it hangs. The hardware is fine — ring/IB tests pass cleanly on a fresh boot. The trigger is the radeon Dynamic Power Management (DPM) reclocking the GPU across suspend/resume, a well-known issue on Northern-Islands/Turks parts. (Log confirms [drm] radeon: dpm initialized.)

Note: switching X11 → Wayland does NOT help — KWin submits to the same ring 0 and hangs identically.

Fix (what worked)

Disable radeon DPM via a kernel boot parameter:

sudo grubby --update-kernel=ALL --args="radeon.dpm=0"
# reboot for it to take effect
sudo reboot

grubby writes this into every BLS boot entry under /boot/loader/entries/ and Fedora carries it forward to newly installed kernels.

Verify after a suspend/resume cycle — this should print nothing:

sudo journalctl -b -k | grep -iE 'radeon.*(lockup|reset|IB on GFX)'

Trade-off: the GPU no longer downclocks at idle, so slightly more idle heat/fan. Negligible in practice.

Undo

sudo grubby --update-kernel=ALL --remove-args="radeon.dpm=0"
sudo reboot

If it ever regresses (e.g. after a kernel update that drops the arg)

  1. Re-apply the grubby command above.
  2. If radeon.dpm=0 alone is no longer enough, add the next-most-common resume-lockup workarounds for this chip, one at a time:
    sudo grubby --update-kernel=ALL --args="radeon.aspm=0"        # disable PCIe ASPM
    sudo grubby --update-kernel=ALL --args="radeon.pcie_gen2=0"   # force PCIe gen1 link

Applying on other distros

The diagnosis and the parameter (radeon.dpm=0) are the same everywhere — only how you persist a kernel boot argument differs. The grubby command above is Fedora/RHEL-family. For other distros, add radeon.dpm=0 to the kernel command line via your bootloader:

  • Debian / Ubuntu / Mint: edit /etc/default/grub, append radeon.dpm=0 inside the quotes of GRUB_CMDLINE_LINUX_DEFAULT, then:
    sudo update-grub && sudo reboot
  • Arch / Manjaro (GRUB): append radeon.dpm=0 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then:
    sudo grub-mkconfig -o /boot/grub/grub.cfg && sudo reboot
    (systemd-boot: add radeon.dpm=0 to the options line of your entry in /boot/loader/entries/*.conf.)
  • openSUSE: add radeon.dpm=0 in YaST → Boot Loader → Kernel Parameters, or edit /etc/default/grub then sudo grub2-mkconfig -o /boot/grub2/grub.cfg && sudo reboot.

The module-option method below is fully distro-agnostic and often the simplest portable choice — only the initramfs-rebuild tool changes: sudo dracut -f (Fedora/Arch/openSUSE) vs sudo update-initramfs -u (Debian/Ubuntu).

Verify after a suspend/resume on any distro — this should print nothing:

sudo journalctl -b -k | grep -iE 'radeon.*(lockup|reset|IB on GFX)'

Persistence method that works on any distro (module option, independent of bootloader)

Instead of (or in addition to) the boot arg, set it as a module option:

echo 'options radeon dpm=0' | sudo tee /etc/modprobe.d/radeon-imac.conf
sudo dracut -f      # rebuild initramfs so it applies at early KMS load
sudo reboot
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment