From: Denis Pisarev <pisarevden@gmail.com>
To: amd-gfx@lists.freedesktop.org
Cc: alexander.deucher@amd.com, christian.koenig@amd.com,
mario.limonciello@amd.com, ionut_n2001@yahoo.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
Denis Pisarev <pisarevden@gmail.com>
Subject: [RFC PATCH v3 0/1] drm/amdgpu: MMIO TLB invalidation fallback when KIQ is wedged after S4 resume
Date: Mon, 24 Aug 2026 17:35:41 +0200 [thread overview]
Message-ID: <20260824153542.491012-1-pisarevden@gmail.com> (raw)
In-Reply-To: <20260819185349.29407-1-pisarevden@gmail.com>
Hi,
v3 addresses the two findings from the sashiko-bot review of v2.
Failure data and trigger isolation are unchanged (bugzilla 219492):
S4 resume on Cezanne (gmc_v9, GFXOFF) wedges KIQ TLB flushes at
80-140/hour for 9+ hours with sched.ready true throughout; holding
GFXOFF off across the S4 cycle produces zero errors.
1. [High] "VFs and interrupt contexts silently drop TLB flushes once
the threshold is reached" - correct, and fixed. In v3 the latch
only reroutes bare metal process context to MMIO. VFs and IRQ
contexts keep submitting to KIQ exactly as before this patch, with
per-failure logging, because they have no MMIO alternative; there
is no longer any code path that drops a flush without attempting
and logging.
2. [High] "KIQ and MMIO race on the same invalidation engine if KIQ
recovers" - this remains the documented open question; no code
change in v3. Our analysis: once latched, this path submits no new
KIQ commands, so the exposure is limited to already-queued stale
commands and the recovery transition window. The engine serializes
requests internally, so the realistic worst case is a lost flush
request caught by the existing ACK timeout ("Timeout waiting for VM
flush ACK!"), not silent state corruption. If maintainers consider
a fence necessary (or a dedicated invalidate engine for the MMIO
path), guidance on the preferred mechanism would be welcome.
Full patch history: v1 (initial fallback+counter), v2 (GFXOFF hold,
per-instance counter, irqsave, VF/IRQ restrictions, MES error
propagation) - all from bot review; v3 (this one) fixes the VF/IRQ
drop regression the bot found in v2.
Also still open from the cover letters: the alternative direction of
fixing the S4 resume ordering itself (RLC/ME vs GFXOFF) instead of a
runtime fallback. Happy to run tracing on the affected hardware.
Patch 1/1 follows.
Denis Pisarev
Denis Pisarev (1):
drm/amdgpu: fall back to MMIO TLB invalidation when KIQ is
unresponsive
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 18 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 2 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 123 +++++++++++++++++++-----
5 files changed, 114 insertions(+), 33 deletions(-)
--
2.55.0
next prev parent reply other threads:[~2026-08-24 15:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 18:53 [RFC PATCH 0/1] drm/amdgpu: MMIO TLB invalidation fallback when KIQ is wedged after S4 resume Denis Pisarev
2026-08-19 18:53 ` [RFC PATCH 1/1] drm/amdgpu: fall back to MMIO TLB invalidation when KIQ is unresponsive Denis Pisarev
2026-08-19 19:06 ` sashiko-bot
2026-08-20 10:57 ` [RFC PATCH v2 0/1] drm/amdgpu: MMIO TLB invalidation fallback when KIQ is wedged after S4 resume Denis Pisarev
2026-08-20 10:57 ` [RFC PATCH v2 1/1] drm/amdgpu: fall back to MMIO TLB invalidation when KIQ is unresponsive Denis Pisarev
2026-08-20 11:11 ` sashiko-bot
2026-08-20 21:10 ` [RFC PATCH 0/1] drm/amdgpu: MMIO TLB invalidation fallback when KIQ is wedged after S4 resume Alex Deucher
2026-08-24 15:35 ` Denis Pisarev [this message]
2026-08-24 15:35 ` [RFC PATCH v3 1/1] drm/amdgpu: fall back to MMIO TLB invalidation when KIQ is unresponsive Denis Pisarev
2026-08-24 18:31 ` [RFC PATCH v3 0/1] drm/amdgpu: MMIO TLB invalidation fallback when KIQ is wedged after S4 resume Alex Deucher
2026-08-24 18:31 ` [RFC PATCH " Christian König
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=20260824153542.491012-1-pisarevden@gmail.com \
--to=pisarevden@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ionut_n2001@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.