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].

We still need root cause why a RCS fault affects the BCS engine - it
shouldn't and need investigation.

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
> 

Reply via email to