From: Stuart Summers <stuart.summers@intel.com>
Cc: intel-xe@lists.freedesktop.org, matthew.brost@intel.com,
Stuart Summers <stuart.summers@intel.com>
Subject: [PATCH 0/7] Fix a couple of wedge corner-case memory leaks
Date: Mon, 13 Oct 2025 22:31:28 +0000 [thread overview]
Message-ID: <20251013223135.189357-1-stuart.summers@intel.com> (raw)
Most of the patches in this series are just adding
some debug hints to help track these down. I split
these up in case we want to pick and choose which ones
to include in the tree. I found them useful.
The main two interesting patches are the last two in the
series which are fixing some corner cases when the
driver becomes wedged in the middle of either communication
with the DRM scheduler or in the event the GuC becomes
unresponsive. In both of these cases there is a chance
we could leak memory around the exec queue members
like the LRC and the LRC BO. These patches fix those
scenarios.
v2: Address feedback from Matt:
- Let the DRM scheduler handle pausing/unpausing
- Still do the wait after scheduling disable/deregister
as with the previous patch, but skip the intermediate
software-based schedule disable using the "banned"
flag and instead just jump straight to the deregister
handling which will fully reset the queue state.
Note that for this case I am seeing a hardware failure
after submitting to GuC but before receiving the
response from GuC. So even if we wedge in this case
(monitoring the hardware state change), the queue
itself is not wedged because of the active GuC
submission (CT is not stalled at that point).
v3: Add back in the xe pause checks and instead just kickstart
message handling in the guc_submi_fini() routine before
doing the async wait there.
Stuart Summers (7):
drm/xe: Add additional trace points for LRCs
drm/xe: Add a trace point for VM close
drm/xe: Add the BO pointer info to the BO trace
drm/xe: Add new exec queue trace points
drm/xe: Correct migration VM teardown order
drm/xe: Kick start GPU scheduler on teardown
drm/xe: Check for GuC responses on disabling scheduling
drivers/gpu/drm/xe/xe_exec_queue.c | 4 +++
drivers/gpu/drm/xe/xe_guc_submit.c | 30 ++++++++++++++++++---
drivers/gpu/drm/xe/xe_lrc.c | 4 +++
drivers/gpu/drm/xe/xe_lrc.h | 3 +++
drivers/gpu/drm/xe/xe_migrate.c | 2 +-
drivers/gpu/drm/xe/xe_trace.h | 22 ++++++++++++++--
drivers/gpu/drm/xe/xe_trace_bo.h | 12 +++++++--
drivers/gpu/drm/xe/xe_trace_lrc.h | 42 +++++++++++++++++++++++++++++-
drivers/gpu/drm/xe/xe_vm.c | 2 ++
9 files changed, 111 insertions(+), 10 deletions(-)
--
2.34.1
next reply other threads:[~2025-10-13 22:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 22:31 Stuart Summers [this message]
2025-10-13 22:31 ` [PATCH 1/7] drm/xe: Add additional trace points for LRCs Stuart Summers
2025-10-13 22:31 ` [PATCH 2/7] drm/xe: Add a trace point for VM close Stuart Summers
2025-10-13 22:31 ` [PATCH 3/7] drm/xe: Add the BO pointer info to the BO trace Stuart Summers
2025-10-13 22:31 ` [PATCH 4/7] drm/xe: Add new exec queue trace points Stuart Summers
2025-10-13 22:31 ` [PATCH 5/7] drm/xe: Correct migration VM teardown order Stuart Summers
2025-10-13 22:31 ` [PATCH 6/7] drm/xe: Kick start GPU scheduler on teardown Stuart Summers
2025-10-13 22:32 ` Summers, Stuart
2025-10-14 2:07 ` Matthew Brost
2025-10-13 22:31 ` [PATCH 7/7] drm/xe: Check for GuC responses on disabling scheduling Stuart Summers
2025-10-14 2:09 ` Matthew Brost
2025-10-14 3:10 ` Summers, Stuart
2025-10-14 1:04 ` ✗ CI.checkpatch: warning for Fix a couple of wedge corner-case memory leaks (rev3) Patchwork
2025-10-14 1:05 ` ✓ CI.KUnit: success " Patchwork
2025-10-14 1:50 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-10-14 10:02 ` ✗ Xe.CI.Full: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2025-10-20 21:45 [PATCH 0/7] Fix a couple of wedge corner-case memory leaks Stuart Summers
2025-10-13 16:24 Stuart Summers
2025-10-13 17:04 ` Matthew Brost
2025-10-13 17:13 ` Summers, Stuart
2025-10-13 21:48 ` Summers, Stuart
2025-10-02 23:04 Stuart Summers
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=20251013223135.189357-1-stuart.summers@intel.com \
--to=stuart.summers@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@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