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
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.
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.
Disable radeon DPM via a kernel boot parameter:
sudo grubby --update-kernel=ALL --args="radeon.dpm=0"
# reboot for it to take effect
sudo rebootgrubby 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.
sudo grubby --update-kernel=ALL --remove-args="radeon.dpm=0"
sudo reboot- Re-apply the
grubbycommand above. - If
radeon.dpm=0alone 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
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, appendradeon.dpm=0inside the quotes ofGRUB_CMDLINE_LINUX_DEFAULT, then:sudo update-grub && sudo reboot - Arch / Manjaro (GRUB): append
radeon.dpm=0toGRUB_CMDLINE_LINUX_DEFAULTin/etc/default/grub, then:(systemd-boot: addsudo grub-mkconfig -o /boot/grub/grub.cfg && sudo rebootradeon.dpm=0to theoptionsline of your entry in/boot/loader/entries/*.conf.) - openSUSE: add
radeon.dpm=0in YaST → Boot Loader → Kernel Parameters, or edit/etc/default/grubthensudo 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)'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