All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.