iMac Late 2015, 27in , 5K (iMac17,1) AMD R9 M380 requires specific kernel parameters for amdgpu to work

[mutahir]

iMac 27" Late 2015 (iMac17,1) — AMD R9 M380 requires specific kernel parameters for amdgpu

Hi Omarchy Dev Team and community,

Thank you for bringing Omarchy to the masses — it's a genuinely brilliant project.

I spent from Saturday morning to Sunday evening (a day and a half!) attempting to get Omarchy running on my iMac Late 2015. This was a joint effort between myself and Claude, and we eventually cracked it. Sharing the full details here in case any other iMac 2015 owners hit the same wall.

Following is a report written by claude on my request to properly document the issue and workaround. I hope that is accepted.

---

The Journey

I first tried the Omarchy 3.4.2 installer directly. It would boot but the screen would go blank/dim after LUKS unlock — keyboard still responsive but no display. Then I tried a manual Arch Linux install, same issue. We tried many kernel parameter combinations over many hours:

• amdgpu.dc=0 — amdgpu probe failed with error -22
• MODULES=(amdgpu) in mkinitcpio — caused hang before LUKS prompt
• nomodeset — booted but only simpledrm (no GPU acceleration, Hyprland impossible)
• amdgpu.cik_support=1 radeon.cik_support=0 — got further but fatal UVD init error -110
• amdgpu.dpm=0 — display changed resolution briefly then died

Eventually I (not claude :-) ) found this Phoronix article which led to the upstream bug report and the working fix.

---

Hardware

Component	Detail
Apple Model	iMac17,1 (27" 5K Retina, Late 2015)
CPU	Intel Core i5-6500 (Skylake)
GPU	AMD Radeon R9 M380 Mac Edition
GPU (Linux name)	Saturn XT [FirePro M6100]
GPU Codename	Bonaire (GCN 2 / Sea Islands / CIK)
PCI Device ID	1002:6640
Apple Subsystem ID	106B:014B
VBIOS	Apple custom — 113-C6005T-009
RAM	32GB DDR3 1867MHz
Kernel	6.19.10-arch1-1
Bootloader	Limine
Display Resolution	4K (3840×2160) — 5K requires additional work, separate issue

---

Problem

Without specific kernel parameters, the amdgpu driver fails fatally on boot:

amdgpu 0000:01:00.0: amdgpu: initializing kernel modesetting (BONAIRE 0x1002:0x6640 0x106B:0x014B 0x80)
[drm:uvd_v4_2_start [amdgpu]] *ERROR* UVD not responding, trying to reset the VCPU!!!
[drm:uvd_v4_2_start [amdgpu]] *ERROR* UVD not responding, giving up!!!
amdgpu 0000:01:00.0: amdgpu: hw_init of IP block <uvd_v4_2> failed -110
amdgpu 0000:01:00.0: amdgpu: Fatal error during GPU init
amdgpu 0000:01:00.0: probe with driver amdgpu failed with error -110

The display dies before or shortly after the LUKS prompt, the system hangs or falls back to simpledrm (basic framebuffer), and Hyprland/Wayland cannot start.

---

Root Cause

Apple's custom VBIOS on the R9 M380 Mac Edition does not properly expose the UVD (Unified Video Decoder) engine to Linux. Additionally, the amdgpu driver does not implement the voltage dependency on the display clock for Sea Islands (CIK/Bonaire) GPUs — the default voltage is not high enough to properly drive the display controller.

This is a confirmed upstream bug, open since June 2024:

• 🔗 https://gitlab.freedesktop.org/drm/amd/-/issues/3425
• 🔗 Direct comment with working fix: https://gitlab.freedesktop.org/drm/amd/-/work_items/3425#note_3338643

---

Fix

Add the following kernel parameters to limine.conf:

amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.ppfeaturemask=0xfff7bffd amdgpu.dc=0

With these parameters, amdgpu loads cleanly and the display works:

lspci -k -d ::03xx
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Saturn XT [FirePro M6100] (rev 80)
    Subsystem: Apple Inc. Tropo XT [Radeon R9 M380 Mac Edition]
    Kernel driver in use: amdgpu

What each parameter does:

Parameter	Purpose
amdgpu.cik_support=1	Enables amdgpu support for CIK/Sea Islands generation GPUs
radeon.cik_support=0	Prevents the legacy radeon driver from claiming the GPU
amdgpu.ppfeaturemask=0xfff7bffd	Disables MCLK DPM (memory clock dynamic power management) which causes the SMU to hang on this Apple VBIOS
amdgpu.dc=0	Disables Display Core — required because the voltage dependency for the display clock is not implemented for this hardware yet

Also add to /etc/modprobe.d/blacklist-radeon.conf:

blacklist radeon

---

Upstream Fix Status

Valve developer Timur Kristóf has identified, reproduced (he acquired the same iMac hardware), and patched this issue. Patches are in review targeting Linux 7.0 (mid-2026):

• 🔗 https://gitlab.freedesktop.org/Venemo/linux/-/commits/ven_smu7_fixes
• 🔗 https://www.phoronix.com/news/Hawaii-Macs-AMDGPU-DC-Fix

Key commits (all pushed March 29, 2026):

Hash	Commit
5b42b318	drm/amdgpu/uvd4.2: Don't initialize UVD 4.2 when DPM is disabled
a204f787	drm/amd/pm/ci: Disable MCLK DPM on problematic CI ASICs
9170e1fa	drm/amd/pm/ci: Use highest MCLK on CI when MCLK DPM is disabled
98bd58d1	drm/amd/pm/smu7: Fix SMU7 voltage dependency on display clock

Once Linux 7.0 lands in Arch, a simple pacman -Syu should make these parameters unnecessary.

---

Note on 4K vs 5K

With the above fix, the display runs at 4K (3840×2160). Getting full 5K (5120×2880) on Linux from these iMacs is a separate, still-unsolved problem requiring OCLP bootloader tricks and additional driver work. 4K is perfectly usable and crisp on this panel — Hyprland with 2x scaling looks excellent.

---

Request

It would be great if Omarchy could consider:

1. Document this hardware requirement so iMac 2015 owners know what kernel params to add before installing — perhaps in a hardware compatibility notes page

2. Protect existing bootloader config during install — or at minimum warn the user and back up limine.conf before touching it
   In my case - the limine conf didn't changed or got overwritten as it preserved the parameters i had added prior to installing omarchy.

3. Eventually drop these params automatically once Linux 7.0 ships the upstream fix

---

System Info — After Successful Omarchy Install

omarchy-version
3.4.2

fastfetch
OS: Omarchy 3.4.2
PC: iMac17,1 (1.0)
CPU: Intel(R) Core(TM) i5-6500 (4) @ 3.60 GHz
GPU: AMD Radeon R9 M380 [Discrete]
Display: 3840x2160 in 27", 60 Hz [Built-in]
Kernel: Linux 6.19.9-arch1-1
Theme: Tokyo Night
Disk: 41.81 GiB / 231.87 GiB (18%) - btrfs
RAM: 1.51 GiB / 31.24 GiB (5%)

It works. Fully. On a 27" 5K iMac. With amdgpu. Running Omarchy 3.4.2 with Hyprland and Tokyo Night.

---

Full Install Journey — Step by Step

For anyone attempting this on the same hardware, here is the exact sequence that worked:

Step 1 — Manual Arch Linux install first
Install Arch Linux manually (standard archinstall or manual). Do NOT use the Omarchy ISO directly — the GPU will fail and you'll get a blank screen with no way to fix it.

Step 2 — Apply kernel parameters before first boot
Before rebooting into your new Arch install, edit /boot/limine/limine.conf and add the params to the cmdline:

amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.ppfeaturemask=0xfff7bffd amdgpu.dc=0

Also add:

echo "blacklist radeon" > /etc/modprobe.d/blacklist-radeon.conf

Step 3 — Install openssh and enable it

pacman -S openssh
systemctl enable sshd

This gives you SSH access as a fallback if display fails.

Step 4 — Verify amdgpu is working
Boot into Arch, unlock LUKS, login. Verify:

lspci -k -d ::03xx
# Expected: Kernel driver in use: amdgpu

fastfetch
# Expected: GPU: AMD Radeon R9 M380 [Discrete]
# Expected: Display: 3840x2160 in 27", 60 Hz [Built-in]

Step 5 — Backup limine.conf

cp /boot/limine/limine.conf ~/limine.conf.bak

Step 6 — Run Omarchy installer

curl -fsSL https://omarchy.org/install | bash

It will ask for sudo password, then your name and email for git config. Runs 5-30 minutes. At the end it reboots automatically.

Step 7 — Verify params survived the Omarchy install
At the Limine boot menu, press E to inspect the Linux entry. Omarchy's installer correctly preserved our kernel parameters in the generated limine.conf. ✓

Step 8 — Boot into Omarchy

• Wait for LUKS prompt — enter your LUKS passphrase
• Omarchy greeter appears — enter your user password
• Hyprland loads, Tokyo Night theme, 4K 60Hz display ✓

Step 9 — Allow SSH through firewall
Omarchy enables ufw by default. Allow SSH:

sudo ufw allow ssh

---

Applying the Fix via Chroot (if you have no display at all)

If your display is completely dead and you can't SSH in, fix limine.conf from the Arch live USB:

# Boot Arch live USB, then find your drive
lsblk

# Open LUKS, mount, chroot
cryptsetup open /dev/sdX2 root
mount -o subvol=@ /dev/mapper/root /mnt
mount /dev/sdX1 /mnt/boot
arch-chroot /mnt

# Edit limine.conf
sed -i 's/amdgpu.dc=0/amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.ppfeaturemask=0xfff7bffd amdgpu.dc=0/' /boot/limine/limine.conf

# Verify
cat /boot/limine/limine.conf

# Exit and reboot
exit
reboot

Replace sdX with your actual drive letter — use lsblk to identify it. On different boots the drive letter may change (sdb, sdc etc) so always verify first.

---

Big thanks to the Omarchy team and especially to Timur Kristóf at Valve for tracking down this hardware bug on decade-old Apple silicon.

fastfetch

                                                              ┌──────────────────────Hardware──────────────────────┐
  ██████████████████████████████████████████████████████       PC: iMac17,1 (1.0)
  ██████████████████████████████████████████████████████      │ ├: Intel(R) Core(TM) i5-6500 (4) @ 3.60 GHz
  ████                     ████                     ████      │ ├: AMD Radeon R9 M380 [Discrete]
  ████                     ████                     ████      │ ├󱄄: 3840x2160 in 27", 60 Hz [Built-in]
  ████    █████████████████████         ████████    ████      │ ├󰋊: 41.81 GiB / 231.87 GiB (18%) - btrfs
  ████    █████████████████████         ████████    ████      │ ├: 1.51 GiB / 31.24 GiB (5%)
  ████    ████                              ████    ████      └ └󰓡 : 0 B / 46.86 GiB (0%)
  ████    ████                              ████    ████      └────────────────────────────────────────────────────┘
  ████    ████                              ████    ████
  ████    ████                              ████    ████      ┌──────────────────────Software──────────────────────┐
  ████    ████                              ████    ████       OS: Omarchy 3.4.2
  ████    ████                              ████    ████      │ ├󰘬: master
  ████████████                              ████    ████      │ ├󰔫: stable
  ████████████                              ████    ████      │ ├: Linux 6.19.9-arch1-1
  ████    ████                              ████    ████      │ ├: /dev/pts/1
  ████    ████                              ████    ████      │ ├󰏖: 924 (pacman)
  ████    ████                              ████    ████      │ ├󰸌: Tokyo Night ●●●●●●●●
  ████    ████                              ████    ████      └────────────────────────────────────────────────────┘
  ████    ████                              ████    ████
  ████    ████                              ████    ████      ┌────────────────Age / Uptime / Update───────────────┐
  ████    ██████████████████████████████████████    ████      󱦟 OS Age: 1 days
  ████    ██████████████████████████████████████    ████      󱫐 Uptime: 23 mins
  ████                     ████                     ████       Update: Sunday, March 29 2026 at 17:06
  ████                     ████                     ████      └────────────────────────────────────────────────────┘
  █████████████████████████████     ████████████████████
  █████████████████████████████     ████████████████████


~ ❯

[cpressland]

Thanks for the detailed issue, I stumbled here trying to find a solution for the same issue on Fedora 43 and this worked flawlessly!

[muyyii]

It would be really nice to find a way to get the full 5k resolution hardware rendered by the amdgpu instead of just relying in the nomodeset parameter for that end.

I've also noticed (distros I've tried: ubuntu - fedora - arch) that the boot time is longer, and during startup black screens/display errors more common if I let the default configuration instead of using nomodeset kernel parameter.

I'll try and test your detailed instructions once I get more free time. It will be a shame not having working these really nice machines. Thanks.

[mutahir]

The 5K resolution issue is being actively investigated upstream. there's good progress on the GitLab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/4455

[yegorrusakovich]

I had similar issue with my iMac Late 2015 27 in AMD R9 M395 Mac Edition. Loading in userspace took 52 seconds and from time to time the system froze with reboot needed.
Fixed the issue when add to limine.conf amdgpu.dpm=0 amdgpu.runpm=0 amdgpu.gpu_recovery=1 pcie_aspm=off (userspace loading now ~3s). Tried amdgpu.dc=0 and broke gui entirely. Experimented with masking specific ip blocks and other options too, no visible effect.
My current config: amdgpu.ppfeaturemask=0xfff7bffd usbcore.autosuspend=-1 amdgpu.ip_block_mask=0x7f amdgpu.dpm=0 amdgpu.runpm=0 amdgpu.gpu_recovery=1 pcie_aspm=off (left useless args in order to preserve stable state, which cost me too much time).
Hope that helps somebody)

[ahmadtv]

@muyyii on native 5K: the work in drm/amd#4455 now runs the panel at full 5120×2880 on amdgpu, both tiles genlocked. It's verified on the 2017 iMac18,3 (my daily machine: https://github.com/ahmadtv/omarchy-imac18-3) and on the iMac Pro. Mark Pronkin's universal patcher (https://github.com/MarkPronkin/imac5k-universal-linux-patcher) accepts the iMac17,1, but its 5K module is still untested there. The 17,1's GPUs are a different generation from the 18,3's, so if one of you tries it, a report in drm/amd#4455 would be the missing data point.

@yegorrusakovich one thing that may be behind the freezes: since kernel 7.1.6 the video encoder in VCE 3 Radeons can hang the GPU during screen recording or hardware H.264 export. That's drm/amd#5595, fixed in 7.3. I've only hit it on Polaris, but the M395 uses the same VCE 3 code in the driver, so if your freezes line up with recording or exporting video, that's a candidate.

[muyyii]

Thank you, I'll give it a try this week(or weekend) and see if I can make it work! I know that the particular hardware of iMac17,1 is complicated, so fingers crossed.

[geirolafs]

Update for the R9 M395 / M395X owners (not the M380 from the original post). You may not need amdgpu.dpm=0 any more.

I used the M395 line from this thread (amdgpu.ppfeaturemask=0xfff7bffd ... amdgpu.ip_block_mask=0x7f amdgpu.dpm=0 ...) for about ten days on an iMac17,1 with the M395X. It fixed the browser freeze, but it also switched off GPU power management (fixed clock) and hardware video decode.

I replaced it with taprobane99's parameters from iMac5KLinux:

amdgpu.ppfeaturemask=0xfff7bbff intel_iommu=on iommu=pt

and kept usbcore.autosuspend=-1 amdgpu.runpm=0 amdgpu.gpu_recovery=1 pcie_aspm=off. I dropped amdgpu.dpm=0 and amdgpu.ip_block_mask=0x7f.

Since then, on Omarchy 4.0.4 with kernel 7.2.5:

• No freeze on first browser start, across many boots with Chrome, video and Half-Life 2.
• Clocks scale again (318–909 MHz). vkmark went from roughly 5,000 to 11,418.
• UVD/VCE are back, so VA-API H.264 decode works (about 6× less CPU on a 1080p clip).

Test it before you commit to it. I added it as a second Limine entry first (a manual entry in /boot/limine.conf pointing at the same UKI with a different cmdline:), booted that a few times, and only then moved it into /etc/default/limine. The old line stays a known-good fallback if the freeze comes back on your unit.

One thing to know with DPM on: the default power profile keeps the core at top clock after every redraw, so the GPU idles warm (~35 W). Setting power_dpm_force_performance_level=manual and then pp_power_profile_mode=2 (POWER_SAVING) through a udev rule brings idle down to ~20 W.

@ahmadtv on native 5K for the iMac17,1: Mark Pronkin's lean stack works here. It runs 5120×2880 in Hyprland on the M395X with both tiles healthy, including after suspend. Details: MarkPronkin/imac5k-universal-linux-patcher#9

---

Investigated, built and written up with Claude Code (Anthropic, model Claude Opus 5.5, claude-opus-5-5), which ran the diagnostics and builds on the machine. I approved and ran the root steps, tested the results on the iMac17,1 above, and reviewed this text before posting.

[geirolafs]

Correction to the above: don't drop ip_block_mask entirely. As @ahmadtv noted, the VCE 3 encoder can hang the GPU on H.264 encode since 7.1.6 (drm/amd#5595, still open; reported on Polaris, same vce_v3_0 code as the M395). Omarchy's screen recording uses hardware H.264.

Use amdgpu.ip_block_mask=0xff instead of 0x7f. That keeps UVD decode (the useful part) and only disables the VCE encoder. Recording falls back to CPU encoding. Revisit on 7.3.