Linux Boots on the M4 Mac Mini After a Fix for a CPU Sleep Instruction That Wipes Registers

A developer who goes by Yureka Lilian has booted Linux to a shell on an M4 Mac mini with all cores running, and the fix for the worst obstacle is merged into mainline Linux and the m1n1 bootloader, according to their October 2 write-up. The same workaround works on the M4 Pro, M4 Max and M5, the post says.

The cause of the hang was a single instruction. On the M4, WFI (wait for interrupt, the instruction a core runs to idle) loses the processor's architectural state, which the Arm specification forbids.

Why the M4 stalled Asahi Linux

The author bought the Mac mini in November 2024 expecting M1-to-M3 style support. The M4 is the first Apple silicon generation to require SPTM, the Secure Page Table Monitor, which hardens macOS's XNU kernel. Earlier ports relied on MMIO traces (records of register accesses) captured while macOS ran under the m1n1 hypervisor, and SPTM broke that method.

Asahi Linux developer Sven Peter wrote in April 2025 that M4 support "is going to be rather painful", in a Mastodon post shown in the write-up; heise covered it at the time. heise reported that SPTM runs at a level the kernel is meant to talk to with the memory management unit already on, which does not work for Linux. heise also reported that project lead Hector Martin had resigned in February 2025.

What the WFI bug does

The post describes three early fixes before the real problem appeared. Two registers that m1n1 wrote on older chips were locked on the M4 and had to be skipped. A missing device-tree entry hid all boot output. After those, the secondary cores started and then crashed unpredictably.

The explanation is in how earlier Apple chips behave. Depending on a vendor control bit, WFI zeroes registers x0 through x31 on M1 to M3. XNU saves them to the stack before idling and restores them after. On those chips m1n1 switches the behaviour off, and Asahi's kernel switches it back on to reach deeper sleep states and let one core boost its clock while the others idle.

On the M4 that bit is either locked or gone, and the default zeroes state. In April 2026 the author got all cores running by replacing every WFI and WFIT (the timed variant) with a no-op in a private kernel.

Date	Event
November 2024	M4 Mac mini bought
April 2025	Sven Peter warns M4 support will be painful
April 2026	All cores boot with WFI replaced by no-ops
October 2, 2026	Fix reported merged in Linux and m1n1

How the fix got upstream

The obvious route, Linux's erratum framework that patches the kernel in memory at boot, was dropped. It cannot reliably tell bare metal from a virtual machine under macOS's hypervisor, which traps WFI to schedule guests, and nested virtualisation makes detection harder still.

Will Deacon suggested a boot argument instead, in a reply on the kernel mailing list. Linux gained an early parameter, idle=<wfi|yield|nop>, plus an override for the timed WFxT variant, and m1n1 now adds the argument on bare-metal machines known to have the fault. The m1n1 change is pull request 672.

The cost is power. Linux on the M4 does not yet reach the deep idle states that the M1 to M3 ports use. The post says the downstream cpuidle-apple driver can fill that gap for now, and that Sven Peter's PSCI EFI conduit work is the likely upstream answer.

What still does not work

Booting to a shell with all cores is the first rung, not a usable desktop. The author lists the built-in camera, the display controller and GPU initialisation as the harder components, all of which wait on Peter's work to run macOS under the hypervisor on M4.

For readers who run models locally on Apple silicon, the practical effect is nil today; the GPU path that tools like the antirez ds4 inference engine use through Metal does not exist on Linux for this chip. For more on how the kernel project handles its own fixes, see Greg Kroah-Hartman on kernel CVEs.

What would change this read

A working GPU driver for M4 would make this a desktop story. Idle power measured against macOS would settle whether the sleep-state gap matters. Neither exists in the post, which reports only that cores boot and run.