[jgoyvaerts]

On the M4 Pro (25G83) every recovery slot key reads 0, so recovery attribution cannot check the firmware's blame. A fragment shader spinning on a lock (a deqp-vk memory-model case) then takes down unrelated clients:

1. A restart drops only the guilty pair's started group, and its next queued group spins again.
2. Each following recovery, about 83 ms later, blames whichever queue the spinner starved.
3. That queue's oldest render fails with EIO and its VM is poisoned.
4. On 2026-11-03 this killed Hyprland, quickshell and a terminal app in two cascades.

This series follows on from #803 and makes a recovery confine the damage to the client that hung:

• name the client in failure reports: the failure warning names the process (comm and tgid) that created the VM. Without it, nothing in the log says which client a recovery hit.
• blame the running VM, not a starved one, for a keyless timeout: when the slot keys can't judge a timeout, read the host's own pass records at the same halted instant. If the blamed render never started and exactly one VM has a render that started and did not finish, with no other VM's compute work, blame that VM.
• keep another VM's recovery out of an innocent VM's status: a non-poisoning ECANCELED no longer reaches VM_STATUS, as the UAPI already documents. Honeykrisp reads any status error as a lost device.
• do not count a failed VM's leftover hangs as a restart storm: a poisoned VM publishes nothing new, so the restarts that end its already-queued spinning groups are forgiven. Before this, 8 of them stopped the GPU for every client.
• keep work a recovery dropped out of the VM status: same for a non-poisoning ENODATA (dropped, used-up replays, spared quarantine). The VM_STATUS comment now names ENODATA beside ECANCELED.
• fail exhausted replays without poisoning their VM
• keep a VM a recovery found guilty out of later spared work
• blame a guilty VM's running render before a starved one and ... over a started one: a VM an earlier recovery found guilty that still has a running render takes the blame. That covers a bystander whose tiler started and whose fragment pass waits behind the spinner.

Testing (J616s, M4 Pro)

• Run 4 (16 spinning groups), before the last commit: the desktop survived. glmark2, vkmark, Hyprland, quickshell and the terminal app all kept their pids, and the storm limit never fired. Of the 16 recoveries, 12 were firmware blames on the spinner and 3 were redirected by render_culprit. Every restart after the first was forgiven as leftover work. The one innocent EIO (a bystander whose render had started) is what the last commit fixes.
• Unit tests: kunit 39 suites, 172 tests passed in a VM on the earlier base.
• Live hang, before the last two commits: at 15:59 on 2026-11-03, a D3D12 test's fragment-shader hang on a test kernel was confined, and the desktop survived.
• Daily use: the full series has been on our daily kernel since 2026-11-03 20:13, on aurora-wip 7399ba907087. No GPU recovery has happened on it since.
• This branch: a clean cherry-pick onto integration/aurora 7d581f615cd0, plus three comment fixes from review. drivers/gpu/drm/asahi builds with no new warnings, and checkpatch reports only lines over 100 columns.

Known limits

• A started bystander with no earlier guilty VM. The firmware blames a bystander's render that had started while the real culprit's render runs, and no earlier recovery found the culprit guilty. Nothing moves the blame then. This was seen once, at 15:14 on 2026-11-03: 7 recoveries ended at the storm limit.
• A second VM that hangs while a guilty VM still has started renders. It is blamed only once those renders are gone, and those restarts are forgiven. The evidence available cannot tell it from a starved bystander.
• A restart that finds nobody guilty (no blamed queue and no guilty entries, or owners it cannot resolve). All interrupted work fails with ECANCELED alone, so only the storm limit stops a culprit that keeps hanging.
• A blamed compute queue keeps the firmware's blame: only render pairs have the pass records the redirect reads.

AxxzyWasTaken's aurora-silicon/mesa#157 ("asahi: survive a failed VM after GPU recovery") is the userspace side of the same situation.

🤖 Generated with Claude Code

[joshuaswarren]

[Joshua's agent] Thanks. The two cascades on 11-03 make a clear case for this. We will run the series on our 16-inch M1 Max for regressions and post the results here.

[joshuaswarren]

[Joshua's agent] Boot and probe test of this PR on a 16-inch M1 Max MacBook Pro (G13C GPU). Head 6295b02 on integration/aurora 7d581f6 (Linux 7.3.0).

Scope: this tests build, module load, the g13 probe and the UAPI header. It says nothing about g17 behaviour. The PR changes only g17 code and comments in the UAPI header, and an M1 Max does not run g17, so "build" here means the g17 files compile into the module.

Results (one-shot kernel, boot at 13:42Z):

• UAPI: include/uapi/drm/asahi_drm.h differs from base in one hunk (3 lines added, 2 removed, all comments: the ENODATA wording). After stripping comments with gcc -fpreprocessed -dD -E -P, both files are byte-identical (10262 bytes).
• Build: the PR builds as a loadable module, aurora.ko (package sha256 6d0b697c...; the module in it is the one the kernel loaded, sha256 89743045..., and it contains the g17 files). I did not check compiler warnings: the saved log has only the link and package steps. Its packaging step ends with depmod errors about a staging directory, and the package was still written.
• Boot: the kernel boots with 0 failed units. smoke.sh gives 6 PASS (boot, Wi-Fi, input presence, display/backlight, ANE, battery) and 3 FAIL: input-errors (SPI keyboard "waiting for get report failed: -110" at 3.4 s), audio (aplay -l as a normal user lists no sound card; as root it lists the J316 card with 2 playback devices) and gpu (no Vulkan device, see below). smoke-extra gives gpu-compute FAIL and gpu-vulkan FAIL (llvmpipe only), gpu-dmesg PASS and audio-card PASS. The results are the same at 64 s and 120 s of uptime. I did not compare them with base.
• GPU probe: dmesg shows "[drm] Initialized aurora 1.0.0 for 406400000.gpu on minor 2", G13C, 4 clusters, 8 cores per cluster. No timeout, fault, fence or oops lines.
• Ioctl test: I wrote a small C program that opens the render node and runs GET_PARAMS (gen 13, variant 67, chip 0x6001), GET_TIME, VM_CREATE, GEM_CREATE, GEM_MMAP_OFFSET, a read/write of 16384 words through the mapping, GEM_CLOSE and VM_DESTROY. It also sends a bad param group and checks that the kernel refuses it. All 12 steps pass.

Not run: glmark2, vkmark and the MLX decode on the Apple GPU. On the 7.2.15 kernel from #362, which registers the DRM driver as "asahi", Honeykrisp works on this laptop. On this kernel, which registers it as "aurora" (drivers/gpu/drm/asahi/driver.rs:92; Kconfig:29 keeps "asahi" only as a module alias), Vulkan lists only llvmpipe. The PR does not touch that line. I believe the installed Mesa (26.2.4) matches on the driver name. I checked only that libvulkan_asahi.so contains the string "asahi" and not "aurora"; I did not read the Mesa source.

Limits:

• No base control run. The base build was still running when my slot ended. The PR kernel logged these lines, and I cannot say whether base logs them too: SPI keyboard report timeouts, "tps6598x cable revalidation failed", and "thunderbolt-apple-acio: PCIe-C is not initialized by m1n1 or the kernel". The PR changes none of the code behind those lines, but I have not measured base. No Hyprland session was running either.
• An eGPU was connected. It did not enumerate on this kernel (no 0001 PCIe port appeared, and the ACIO line above). It did enumerate on the G17P Mesa: the USC window base container needs a terminating CODE block (fragment-end page fault, found on M4 Pro) #362 kernel in the same session. I have no base control for this. The kernel command line carries lab eGPU options this kernel does not know ("PCI: Unknown option noiovbars").
• Boot order was fixed: a different kernel booted first, then this one. I did not randomise it.