From: Javier MV <javiermv@gmail.com>
To: intel-gfx@lists.freedesktop.org
Cc: Javier MV <javiermv@duck.com>,
jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
rodrigo.vivi@intel.com, tursulin@ursulin.net,
matthew.brost@intel.com, daniele.ceraolospurio@intel.com,
umesh.nerlige.ramappa@intel.com
Subject: [PATCH 1/2] drm/i915/guc: Complete all requests of a non-schedulable context
Date: Tue, 10 Nov 2026 12:24:47 +0000 [thread overview]
Message-ID: <20261110122534.12989-2-javiermv@gmail.com> (raw)
In-Reply-To: <20261110122534.12989-1-javiermv@gmail.com>
From: Javier MV <javiermv@duck.com>
When the context of a request being submitted is banned or exiting,
__guc_add_request() marks the request as complete with -EIO instead of
submitting it. But guc_dequeue_one_context() merges all queued requests
of a context and only passes the last one to __guc_add_request(). The
earlier ones were moved to ce->guc_state.requests by
__i915_request_submit(), which only skips their payload: they still
need the GPU to run the context and write their breadcrumbs.
After a full GT reset the banned context is no longer registered with
GuC and is never registered again, so those requests never complete.
Nothing retires them, the buffers they reference stay pinned, and the
client waits on their fences forever.
Seen on ADL-P with a Vulkan compute job (llama.cpp) and a short
request_timeout_ms: a GuC context reset, the ban, the replay moving
10 requests back to the queue, then a full GT reset after a stopped
heartbeat. Afterwards the context was unregistered and the GuC submit
queue was empty, but 9 of its requests never completed: 7.5 GB of
objects stayed pinned after the process was killed.
Complete every request on the context's list, as
guc_cancel_context_requests() does, but only when the context is off
the HW (not enabled, no enable or disable in flight), so a request that
is still executing is never marked complete.
Found and fixed with Claude Code (AI coding assistant); details in the
cover letter.
Fixes: ae8ac10dfd2a ("drm/i915/guc: Implement banned contexts for GuC submission")
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15301
Signed-off-by: Javier MV <javiermv@duck.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 788e59c..555ca8f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -709,6 +709,20 @@ static int __guc_add_request(struct intel_guc *guc, struct i915_request *rq)
* request resubmitted after the context was banned.
*/
if (unlikely(!intel_context_is_schedulable(ce))) {
+ struct i915_request *pos;
+
+ /*
+ * The dequeue only passes the last of the merged requests, and
+ * the context won't run again to write the others' breadcrumbs:
+ * complete them all, once the context is off the HW.
+ */
+ spin_lock(&ce->guc_state.lock);
+ if (!context_enabled(ce) && !context_pending_enable(ce) &&
+ !context_pending_disable(ce))
+ list_for_each_entry(pos, &ce->guc_state.requests, sched.link)
+ i915_request_put(i915_request_mark_eio(pos));
+ spin_unlock(&ce->guc_state.lock);
+
i915_request_put(i915_request_mark_eio(rq));
intel_engine_signal_breadcrumbs(ce->engine);
return 0;
--
2.51.1
next prev parent reply other threads:[~2026-11-10 12:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 12:24 [PATCH 0/2] drm/i915/guc: Fix requests of a banned context never completing Javier MV
2026-11-10 12:24 ` Javier MV [this message]
2026-11-10 12:56 ` [PATCH 1/2] drm/i915/guc: Complete all requests of a non-schedulable context sashiko-bot
2026-11-10 12:24 ` [PATCH 2/2] drm/i915/guc: Don't unblock a banned context Javier MV
2026-11-10 13:07 ` sashiko-bot
2026-11-10 15:11 ` ✗ LGCI.VerificationFailed: failure for drm/i915/guc: Fix requests of a banned context never completing Patchwork
2026-11-11 15:29 ` [PATCH 0/2] " Javier MV
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261110122534.12989-2-javiermv@gmail.com \
--to=javiermv@gmail.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=javiermv@duck.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=tursulin@ursulin.net \
--cc=umesh.nerlige.ramappa@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox