Repository navigation
drm/asahi: g17: keep an exited owner's compute backing until another VM needs the queue - #1503
Merged
RyanTheTide merged 1 commit intoNov 11, 2026
Conversation
…VM needs the queue detach_exited_owner() marked every idle compute queue whose owner exited for fresh backing, so each short-lived process's queue went through a pool release and re-arm right after its owner left. On the Neo (G17P), a long Vulkan CTS session then retired a compute command on its completion record without a completion stamp, and from there every later client's work timed out (ETIMEDOUT) until reboot. The per-VM tie does not need the eager release: pool_serves() already refuses to bind the backing for any VM other than the one it served, and the QID-pressure path marks a queue serving another VM for fresh backing before that VM may use it. Keep the exited owner's backing tied to its VM and leave the release to that path. Same order on the Neo (fresh boot, 36,127-case CTS slice with 4 deqp-vk processes, then 30 runs of three timeline semaphore one_to_n cases): integration fc0a069 lost the device in the slice and in 8 of the 30 runs; with this change, 5 of 5 sessions had no device loss and no ETIMEDOUT. Fixes: b3b02e2 ("drm/asahi: g17: Fix compute scratch leaking across processes on queue reuse") Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
This was referenced Nov 11, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
detach_exited_owner() marked every idle compute queue whose owner exited for fresh backing, so each short-lived process's queue went through a pool release and re-arm right after its owner left. On the Neo (G17P), a long Vulkan CTS session then retired a compute command on its completion record without a completion stamp, and every later client's work timed out (ETIMEDOUT, g17/runtime/backend.rs:235) until reboot.
The per-VM tie does not need the eager release:
pool_serves()already refuses to bind the backing for a VM other than the one it served, and the QID-pressure path marks a queue serving another VM for fresh backing before that VM may use it. This keeps the exited owner's backing tied to its VM and leaves the release to that path.Fixes: b3b02e2 ("drm/asahi: g17: Fix compute scratch leaking across processes on queue reuse")
Tests (Neo, J700/G17P, Mesa c208afc352, Vulkan CTS 1.4.7.0)
Each session: fresh boot, the 36,127-case CTS slice with 4 deqp-vk processes, then 30 runs of three
dEQP-VK.synchronization{,2}.timeline_semaphore.one_to_n.*cases.Bisect of the same test over the first-parent chain of #1012 (GPU driver files of commit X on the same base): 1472610 good (3 sessions clean), b3b02e2 bad.
🤖 Generated with Claude Code