On 19-09-2026 04:01, Matthew Brost wrote:
On Wed, Sep 16, 2026 at 03:23:32PM +0530, Arvind Yadav wrote:
On BMG, terminating a process with Ctrl+C while GPU work is running under
VRAM pressure can cause an RCS page fault followed by a migration queue
timeout on BCS8 (guc_id 0). The driver resets the GT, but the pending
migration job can time out again and eventually wedge the device.
If we can just avoid faults on ctrl-c or segfault will this series be
needed (or at least only a subset of this series)?
I suggested a way to kill the exec queue first + sync wait on those here
[1] before clobbering the GPU page tables? I don't really care who works
on [1].
Thankyou Matt for you review comments and suggestions.
My series waits for final queue cleanup before removing the VM mappings.
Your suggestion is to disable all queues first, then wait for them to
stop before calling xe_vm_close().
I will build on your v6 patch and add the synchronous wait from the
earlier discussion. I will test that approach and check which parts of
my series are still needed.
We still need root cause why a RCS fault affects the BCS engine - it
shouldn't and need investigation.
I will also continue the GuC investigation into the first BCS8 failure.
Avoiding the teardown fault may prevent this reproducer, but it does not
explain why the RCS fault affects BCS8.
I am discussing this issue with the GuC team, and once we identify the
root cause, I will provide an update.
Thanks,
Arvind
Matt
[1]
https://patchwork.freedesktop.org/patch/752845/?series=173889&rev=1#comment_1391707
BCS8 is reserved for paging and runs migration and VM bind work.
The exact hardware link between the RCS fault and the BCS8 stall
is still under investigation. This series addresses the teardown
and recovery problems found while debugging this failure.
During file close, exec queue cleanup starts asynchronously, but the VM
mappings can be removed before that cleanup finishes. A missed wakeup in
the GuC disable-completion handler can also turn a completed operation
into a five-second timeout and an unnecessary GT reset.
The reset replay path rewinds the software ring tail to the oldest pending
job, but leaves the LRC head at its saved position. This leaves different
starting positions for replay.
The four patches address these paths:
1. Clear pending-disable state before waking waiters, so a completed disable
does not appear to time out.
2. Mark VMs as closing before queue cleanup. Reject new work and page faults
on closing VMs, while allowing existing SVM invalidation to drain mappings.
3. Keep VM mappings alive until queue cleanup completes. File close uses one
five-second queue-wait budget across all VMs, then defers any remaining
teardown.
VM destroy defers without waiting. Device references protect deferred close and
final VM destruction on the module-lifetime destroy workqueue.
4. Set the software tail and LRC head and tail to the oldest pending job before
resubmitting jobs after a GT reset.
The five-second budget applies only to the new queue-cleanup wait.
Existing teardown waits are unchanged.
Arvind Yadav (5):
drm/xe: Hold a device reference across deferred VM destruction
drm/xe/guc: Wake disable waiters after clearing pending state
drm/xe: Mark VMs as closing before queue cleanup
drm/xe: Defer VM teardown until exec queue cleanup completes
drm/xe/guc: Reset LRC ring pointers before replay
drivers/gpu/drm/xe/xe_device.c | 25 +++-
drivers/gpu/drm/xe/xe_exec_queue.c | 22 +++-
drivers/gpu/drm/xe/xe_guc_submit.c | 60 +++++----
drivers/gpu/drm/xe/xe_module.c | 6 +-
drivers/gpu/drm/xe/xe_pagefault.c | 2 +-
drivers/gpu/drm/xe/xe_svm.c | 3 +-
drivers/gpu/drm/xe/xe_vm.c | 205 +++++++++++++++++++++++++----
drivers/gpu/drm/xe/xe_vm.h | 14 +-
drivers/gpu/drm/xe/xe_vm_types.h | 16 +++
9 files changed, 289 insertions(+), 64 deletions(-)
--
2.43.0
