[jgoyvaerts]

Problem

Each g17 queue recorded the earliest failed ordinal per engine (failures[engine]) and kept it for the queue's lifetime. Any later command whose prefix covered that ordinal was cancelled. GL submits with a full prefix (every command orders after every earlier one), so after one failed command, every later command of that queue was cancelled too, forever.

Since cancellation is no longer reported as a device loss, the client never notices. Seen on a J616s (M4 Pro):

• CS2 hangs the GPU.
• One Hyprland render that sampled the game's failed buffer is cancelled.
• Every later Hyprland render is cancelled as well: about 47 a second, all fences ECANCELED.
• The screen keeps the game's last frame until Hyprland or the machine restarts. New buffers do not help, because the queue itself is poisoned.

Fix

The record exists so that nothing runs before a failed producer that the firmware may still own or replay. That only holds while the command keeps its VM pin:

• complete() and fail_unpublished() release the pin.
• fail_while_owned() keeps it until release_after_retirement().

FailureRecord now tracks the failed commands that still hold their pin, and drops each one once it has released the pin. A failure that cannot be tracked because memory runs out still cancels for good, as before.

Testing

• KUnit (asahi_g17_dependency, new): 4 tests. Three of them fail on the old keep-forever behaviour. 188/188 pass on integration/aurora with the change.
• Live, J616s, 7.3 + this change:
  • CS2 hung the GPU and lost its device.
  • Hyprland kept drawing: its fences signalled successfully, 0 cancellations, about 380 renders in 4 s after the recovery.
  • Without the change, the same repro froze the desktop every time (4 times today).

Relation to #433

This is independent of #433 and applies cleanly to integration/aurora without it. #433 keeps innocent clients alive across another client's recovery. This change stops a client's own queue from staying poisoned after one cancelled command. The two are complementary: with #433 alone, the desktop still froze after a CS2 hang.

Assisted-by: LLM

[RyanTheTide]

Merged into integration/aurora. Hardware: on the J616s a second client submitted a hanging dispatch while glmark2 looped (4 runs around 7000, 6928 after): the other client kept completing, no stray cancels, no GPU faults, journalctl -k -p 3 empty, no WARN or DART faults. The M2, M1 Pro and Neo passed with it in the integration candidate, including 3 concurrent glmark2 clients for 60 s with 0 GPU errors. Thanks!