[PATCH v2 0/2] drm/i915/guc: Fix requests of a banned context never completing

[PATCH v2 0/2] drm/i915/guc: Fix requests of a banned context never completing

[Javier MV]

From: Javier MV <javiermv@duck.com>

On ADL-P with GuC submission, a GuC context reset of a context whose requests
are being cancelled by the request watchdog can leave that context's requests
incomplete forever. The client waits on their fences forever, and if it is
killed its buffers stay pinned until reboot (here 7.5 GB of Shmem/Unevictable,
with the process gone from DRM clients).
Reported in https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15301.

The sequence, from instrumented runs (a llama.cpp Vulkan compute job,
request_timeout_ms=2000 via debugfs, preempt_timeout_ms=7500):

 1. The watchdog cancels a request: guc_context_cancel_request() blocks the
    context (schedule disable) to skip it.
 2. GuC can't preempt the compute work (no mid-thread preemption on Gen12) and
    resets the context instead. The reset handler captures, bans (revoke finds
    the disable pending, so it only sets a 1 ms preemption timeout) and replays,
    which unwinds the incomplete requests back to the scheduler queue.
 3. The late schedule disable done G2H clears SCHED_STATE_BANNED and cancels
    nothing (the list is already empty), then guc_context_unblock() enables
    scheduling of the banned context.
 4. Either the resubmitted requests run as NOPs and everything retires
    (harmless), or GuC resets the context again at the first preemption (1 ms
    timeout). That second notification is ignored for a banned context, so its
    submitted requests never complete. In one run this was followed by G2H
    action 0x6000 rejected with -EOPNOTSUPP, a stopped rcs0 heartbeat and a
    full GT reset; after it the context was no longer registered, and the
    dequeue only marks the last of a banned context's merged requests
    complete, so the other 9 never completed.

Patch 1 completes all requests of a non-schedulable context on resubmission
(once it is off the HW), and patch 2 stops unblock from re-enabling a banned
(or exiting) context.

A reset notification for an already banned context is still ignored. I didn't
see one with this series, so it doesn't change that, but if one can still
happen some other way, that context's requests could stay incomplete. I have
an additional patch for that case, which cancels the requests on such a
notification. It has never run in my tests because I couldn't reach that path
with these patches applied, so I left it out, but I can send it if you want it.

Tested on i5-1235U (ADL-P GT2, 8086:46a8), GuC 70.36.0, on top of Ubuntu's
7.0.0-42 (mainline 7.0.14; the touched code is identical in mainline as of
2026-10-29). Without the series: 5 hangs in 17 runs with the setup above
(some with other GPU or CPU load), one of them leaked as described (as did
an earlier run on the stock module). With v1 of this series: 30 runs, 1
hang (the ecode of the run that leaked): no full GT reset, the client got
VK_ERROR_DEVICE_LOST instead of waiting forever, nothing stayed pinned.
Instrumented builds that also carried the additional patch above, which never
fired: 20 runs with both patches, 2 hangs of the leaking kind (same ecodes as
before), handled the same way, and the logs show no second reset; 20 runs with
patch 1 alone, 1 hang, also contained.

With v2 (same setup): 30 runs, 4 hangs, all contained the same way
(VK_ERROR_DEVICE_LOST, nothing stayed pinned). In one of them GuC failed
the engine reset and i915 reset the whole GT, which I had also seen
without the series; it ended the same way.

I can reproduce this here, though a hang takes 10 to 30 runs. If it helps, I
can send the full log of a hang from the instrumented build, attach error
states, or test a different approach if you'd rather fix it another way.

Tool disclosure: I did this work with Claude Code (Opus 5.5), over several
sessions. I reported the symptoms, ran it on my machine and decided what to
pursue. The assistant read the i915 sources and the logs, wrote the debug
instrumentation and test scripts, worked out the sequence above, and wrote both
patches, their changelogs and most of this letter. The logs and results quoted
here come from runs on my machine. I have checked the sequence and the patches
against the code and can answer for them.

Changes in v2 (both from the Sashiko review of v1):
- Patch 1: v1 completed the submitted request again after dropping the
  lock, although the loop had already completed it, so it could have
  been retired and freed in between. v2 completes it either in the loop
  (context off the HW) or on its own (context still on the HW), both
  under the lock, and doesn't touch it after the unlock.
- Patch 2: check !intel_context_is_schedulable() instead of
  intel_context_is_banned(), since revoke takes the same path for exiting
  contexts.
- Not changed: the other two findings on patch 1 (only the last request
  completed while the context is still on the HW, and requests left with
  an enable pending) are about the on-HW path, which still completes only
  the submitted request, as it did before this series (now under the
  lock).

v1: https://lore.kernel.org/intel-gfx/20261110122534.12989-1-javiermv@gmail.com/

Patchwork CI didn't run on v1 (my address isn't on the CI allowlist). If
someone can trigger it for this version, I'd appreciate it.

Javier MV (2):
  drm/i915/guc: Complete all requests of a non-schedulable context
  drm/i915/guc: Don't unblock a non-schedulable context

 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25 ++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)


base-commit: d89e1d186ec9271bf78e62771779e9fc03bf0fc3
-- 
2.51.1

[PATCH v2 1/2] drm/i915/guc: Complete all requests of a non-schedulable context

[Javier MV]

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. The submitted request is
on that list too, so it is completed on its own only when the context
is still on the HW, and nothing touches it after the lock is dropped:
once complete it can be retired and freed.

Found and fixed with Claude Code; 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>
---
v2:
- Complete rq on its own only when the loop doesn't run, under the
  lock. v1 completed it again after the unlock, when the loop had
  already completed it and it could have been retired and freed
  (Sashiko).

 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 20 ++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

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..b2ffc6b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -709,7 +709,25 @@ 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))) {
-		i915_request_put(i915_request_mark_eio(rq));
+		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 (rq is on the list too), once the context
+		 * is off the HW. Don't touch rq after the unlock: once complete
+		 * it can be retired and freed.
+		 */
+		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));
+		} else {
+			i915_request_put(i915_request_mark_eio(rq));
+		}
+		spin_unlock(&ce->guc_state.lock);
+
 		intel_engine_signal_breadcrumbs(ce->engine);
 		return 0;
 	}
-- 
2.51.1

[PATCH v2 2/2] drm/i915/guc: Don't unblock a non-schedulable context

[Javier MV]

From: Javier MV <javiermv@duck.com>

guc_context_cancel_request() blocks the context, skips the request and
unblocks the context again. If the context gets banned meanwhile (the
blocked request hits a GuC context reset), guc_context_revoke() finds
the schedule disable of the block still pending, so it only sets the
preemption timeout to 1 ms and leaves the cancellation to the schedule
disable done handler. That handler clears SCHED_STATE_BANNED, and then
guc_context_unblock() finds nothing in context_cant_unblock() that
stops it from enabling scheduling again.

GuC then runs a banned context with a 1 ms preemption timeout and
resets it again at the first preemption. Seen on ADL-P: the second
reset notification was ignored, GuC sent G2H messages the driver
rejected (action 0x6000, -EOPNOTSUPP), the rcs0 heartbeat stopped and
the whole GT was reset, which also kills every other client's work.

Also check intel_context_is_schedulable(), whose CONTEXT_BANNED and
CONTEXT_EXITING flags stay set. Exiting contexts need it too: revoke
takes the same SCHED_STATE_BANNED path for them, so the same race can
re-enable a revoked context. The requests the replay put back in the
queue are then completed on resubmission, as for any banned context.

Found and fixed with Claude Code; details in the cover letter.

Fixes: 9888beaaf118 ("drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, not registered")
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15301
Signed-off-by: Javier MV <javiermv@duck.com>
---
v2:
- Check !intel_context_is_schedulable() instead of
  intel_context_is_banned(): revoke takes the same path for exiting
  contexts (Sashiko).

 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +++++
 1 file changed, 5 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 b2ffc6b..966c23e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3186,7 +3186,12 @@ static bool context_cant_unblock(struct intel_context *ce)
 {
 	lockdep_assert_held(&ce->guc_state.lock);
 
+	/*
+	 * SCHED_STATE_BANNED alone isn't enough: the sched disable done
+	 * handler clears it. Revoke sets it for exiting contexts too.
+	 */
 	return (ce->guc_state.sched_state & SCHED_STATE_NO_UNBLOCK) ||
+		!intel_context_is_schedulable(ce) ||
 		context_guc_id_invalid(ce) ||
 		!ctx_id_mapped(ce_to_guc(ce), ce->guc_id.id) ||
 		!intel_context_is_pinned(ce);
-- 
2.51.1

Re: [PATCH v2 1/2] drm/i915/guc: Complete all requests of a non-schedulable context

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] drm/i915/guc: out-of-order request completion in
  __guc_add_request()
--

commit ab2fec244e71c5f1800fda0182eb817d04ef826f
Author: Javier MV <javiermv@duck.com>

drm/i915/guc: Complete all requests of a non-schedulable context

When submitting a request for a non-schedulable context, this commit marks
all requests on ce->guc_state.requests complete with -EIO once the context
is off the hardware.

Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15301

> 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 788e59cdfac9b..b2ffc6b4614e4 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -709,7 +709,25 @@ 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))) {
> -		i915_request_put(i915_request_mark_eio(rq));
> +		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 (rq is on the list too), once the context
> +		 * is off the HW. Don't touch rq after the unlock: once complete
> +		 * it can be retired and freed.
> +		 */
> +		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));
> +		} else {
> +			i915_request_put(i915_request_mark_eio(rq));
> +		}

[Severity: High]
Does the else branch complete rq out of order ahead of earlier requests on
the same timeline?

Before calling __guc_add_request(), guc_dequeue_one_context() and
guc_bypass_tasklet_submit() move every submitted request onto
ce->guc_state.requests via __i915_request_submit() and pass only the final
request as rq.  When the context is still on the hardware or has an enable
or disable in flight, marking only rq complete leaves earlier merged or
in-flight requests on ce->guc_state.requests and tl->requests incomplete.

Because __i915_active_fence_set() moves active tracking callbacks to the
newest request on the timeline, completing rq early retires vma->active and
ce->active while the GPU is still executing earlier requests on the context,
and trips the check in i915_request_retire_upto():

drivers/gpu/drm/i915/i915_request.c:i915_request_retire_upto() {
	do {
		tmp = list_first_entry(&tl->requests, typeof(*tmp), link);
		GEM_BUG_ON(!i915_request_completed(tmp));
	} while (i915_request_retire(tmp) && tmp != rq);
}

Also, if context_pending_enable(ce) is set while !context_enabled(ce) &&
!context_pending_disable(ce) (for example after __guc_reset_context() clears
SCHED_STATE_ENABLED while an enable G2H is still in flight),
intel_guc_sched_done_process_msg() only clears SCHED_STATE_PENDING_ENABLE
without calling guc_cancel_context_requests(), so the earlier merged
requests are never completed.

Since rq is already on ce->guc_state.requests, should the else branch leave
rq incomplete so guc_cancel_context_requests() completes the whole list in
order once the context is off the hardware?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111135753.11071-1-javiermv@gmail.com?part=1

✗ LGCI.VerificationFailed: failure for drm/i915/guc: Fix requests of a banned context never completing (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Fix requests of a banned context never completing (rev2)
URL   : https://patchwork.freedesktop.org/series/178201/
State : failure

== Summary ==

Series author address 'javiermv@gmail.com' is not on the allowlist, which prevents CI from being automatically triggered.
If you want CI to run for this series, ask Patchwork project owners to click 'retest' on the series in Patchwork.
Exception occurred during validation, bailing out!
Build URL: http://gfx-ci.igk.intel.com:8080/job/CI_PW_kernel/193001/ (on built-in)

Re: [PATCH v2 1/2] drm/i915/guc: Complete all requests of a non-schedulable context

[Vivi, Rodrigo]

On Wed, 2026-11-11 at 13:57 +0000, Javier MV wrote:
> 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. The submitted request is
> on that list too, so it is completed on its own only when the context
> is still on the HW, and nothing touches it after the lock is dropped:
> once complete it can be retired and freed.
> 
> Found and fixed with Claude Code; details in the cover letter.

This commit message will be part of git history, while the cover letter
won't. So this message doesn't belong here to start with.
The commit needs to be self sufficient and self explained.
Also, please ask your LLM to be concise in the messages and to
avoid unnecessary comments. A good code talks for itself.

With short texts your chances of getting a reviewer increases.

> 
> 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>
> ---
> v2:
> - Complete rq on its own only when the loop doesn't run, under the
>   lock. v1 completed it again after the unlock, when the loop had
>   already completed it and it could have been retired and freed
>   (Sashiko).
> 
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 20
> ++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> 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..b2ffc6b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -709,7 +709,25 @@ 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))) {
> -		i915_request_put(i915_request_mark_eio(rq));
> +		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 (rq is on the list too), once
> the context
> +		 * is off the HW. Don't touch rq after the unlock:
> once complete
> +		 * it can be retired and freed.
> +		 */
> +		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_e
> io(pos));
> +		} else {
> +			i915_request_put(i915_request_mark_eio(rq));
> +		}
> +		spin_unlock(&ce->guc_state.lock);
> +
>  		intel_engine_signal_breadcrumbs(ce->engine);
>  		return 0;
>  	}

Re: [PATCH v2 1/2] drm/i915/guc: Complete all requests of a non-schedulable context

[Javier MV]

On the out-of-order completion in the else branch: that branch keeps the
existing behaviour (only rq is completed, as before this patch). The patch
adds the off-HW case and moves the existing call under the lock.

Leaving rq incomplete there looks right while the context is still enabled
or has a disable in flight. Every path that makes a context non-schedulable
calls guc_context_revoke() right after setting the flag. The schedule
disable that revoke sends, or the one already pending, then completes with
SCHED_STATE_BANNED set, and its done handler cancels the whole list in order.

I'm less sure about the pending enable case. As the review says, the enable
done handler cancels nothing, and revoke has already run by then. So unless
the context runs again, rq would never complete, where today it at least
gets completed. My instrumented runs only logged the off-HW path, so I have
no data on how often either state happens.

If you'd like this handled in this series, I can send a v3 that leaves rq
to the cancel when a disable is pending or the context is enabled, and
keeps the current behaviour for a pending enable.

Javier MV