From: "Tales A. Mendonça" <talesam@gmail.com>
To: intel-xe@lists.freedesktop.org
Cc: matthew.brost@intel.com, thomas.hellstrom@linux.intel.com,
rodrigo.vivi@intel.com, dri-devel@lists.freedesktop.org,
"Tales A. Mendonça" <talesam@gmail.com>
Subject: [RFC PATCH 0/3] drm/xe: diagnostics and workaround for GuC TLB invalidation ack stalls on ARL
Date: Mon, 3 Aug 2026 23:14:38 -0300 [thread overview]
Message-ID: <20260804021441.3054424-1-talesam@gmail.com> (raw)
Hi,
This series is a follow-up to the TLB invalidation ack stall I have
been debugging on ARL, tracked in:
https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8678
Summary of the issue: with GuC 70.53.0 on ARL (reproduced on 7d51 and
7dd1 machines here, plus an independent Arc Pro 130T report on the
issue above), TLB invalidation acks intermittently stall for ~2.3s.
The H2G request is consumed from the CTB immediately and the G2H CTB
is empty the whole time - the firmware simply does not send the ack
until much later. The fence timeout fires at 2.25s and the ack lands
tens of ms after it. Userspace blocked on the invalidation (compositor
buffer unmaps etc.) hitches for the full window.
Patch 1 adds xe_devcoredump_gt() so this kind of hang - which has no
exec queue or job to blame - leaves a devcoredump with the GuC log and
CT state behind (Matt suggested capturing devcoredumps when we
discussed the issue; devcoredumps from both machines are attached to
the issue above).
Patch 2 logs when the ack for a timed out invalidation finally
arrives. This is what established that the acks are late rather than
lost.
Patch 3 is the RFC part: a delayed work that pokes the GuC (status
register read, CT flush, doorbell ring) every 250ms while an ack is
overdue. On my machines this converts the guaranteed 2.3s stall into a
sub-500ms hiccup for the majority of occurrences; a minority of severe
episodes ignore 8-9 consecutive doorbells, which points at the GuC
firmware being internally blocked for the whole window. Full data on
the issue. I am happy to rework the approach (different delay,
tying it to the G2H handler, dropping the status read, etc.) - mainly
I would like the firmware side investigated, since no host-side poke
can fix the severe cases.
Based on drm-tip. Tested for several days on both ARL machines under
desktop and VM-heavy workloads.
Thanks,
Tales
Tales A. Mendonça (3):
drm/xe: Capture devcoredump on TLB invalidation timeout
drm/xe: Log when a timed out TLB invalidation ack finally arrives
drm/xe: Kick GuC while TLB invalidation acks are overdue
drivers/gpu/drm/xe/xe_devcoredump.c | 68 ++++++++++++
drivers/gpu/drm/xe/xe_devcoredump.h | 6 ++
drivers/gpu/drm/xe/xe_tlb_inval.c | 131 +++++++++++++++++++++++-
drivers/gpu/drm/xe/xe_tlb_inval_types.h | 42 ++++++++
4 files changed, 243 insertions(+), 4 deletions(-)
--
2.55.0
next reply other threads:[~2026-08-04 2:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 2:14 Tales A. Mendonça [this message]
2026-08-04 2:14 ` [RFC PATCH 1/3] drm/xe: Capture devcoredump on TLB invalidation timeout Tales A. Mendonça
2026-08-04 2:14 ` [RFC PATCH 2/3] drm/xe: Log when a timed out TLB invalidation ack finally arrives Tales A. Mendonça
2026-08-04 2:14 ` [RFC PATCH 3/3] drm/xe: Kick GuC while TLB invalidation acks are overdue Tales A. Mendonça
2026-08-04 2:15 ` ✗ LGCI.VerificationFailed: failure for drm/xe: diagnostics and workaround for GuC TLB invalidation ack stalls on ARL Patchwork
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=20260804021441.3054424-1-talesam@gmail.com \
--to=talesam@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.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