From: Andi Shyti <andi.shyti@linux.intel.com>
To: Nirmoy Das <nirmoy.das@linux.intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>,
Nirmoy Das <nirmoy.das@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
John.C.Harrison@intel.com
Subject: Re: [PATCH v2 2/2] drm/i915: Fix gt reset with GuC submission is disabled
Date: Tue, 23 Apr 2024 16:42:51 +0200 [thread overview]
Message-ID: <ZifI63mDmzFkLAJQ@ashyti-mobl2.lan> (raw)
In-Reply-To: <0df81d37-3cc6-4f60-9111-1f579e51ff18@linux.intel.com>
Hi Nirmoy,
> > > Currently intel_gt_reset() kills the GuC and then resets requested
> > > engines. This is problematic because there is a dedicated CSB FIFO
> > > which only GuC can access and if that FIFO fills up, the hardware
> > > will block on the next context switch until there is space that means
> > > the system is effectively hung. If an engine is reset whilst actively
> > > executing a context, a CSB entry will be sent to say that the context
> > > has gone idle. Thus if reset happens on a very busy system then
> > > killing GuC before killing the engines will lead to deadlock because
> > > of filled up CSB FIFO.
> > is this a fix?
>
> I went quite far back in the commit logs, and it appears to me that we've
> always been using the current reset flow.
>
> I believe we don't perform a GT reset immediately after sending a number of
> requests, which is what the current failed test is doing.
>
> So, I don't think there will be any visible impact on the user with the
> current flow.
Agree... good thinking here... we often abuse on the Fixes tag.
Thanks,
Andi
next prev parent reply other threads:[~2024-04-23 14:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 20:19 [PATCH v2 1/2] drm/i915: Refactor confusing __intel_gt_reset() Nirmoy Das
2024-04-22 20:19 ` [PATCH v2 2/2] drm/i915: Fix gt reset with GuC submission is disabled Nirmoy Das
2024-04-23 0:09 ` John Harrison
2024-04-23 9:32 ` Andi Shyti
2024-04-23 10:45 ` Nirmoy Das
2024-04-23 14:42 ` Andi Shyti [this message]
2024-04-22 21:14 ` ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915: Refactor confusing __intel_gt_reset() Patchwork
2024-04-22 21:20 ` ✓ Fi.CI.BAT: success " Patchwork
2024-04-23 0:07 ` [PATCH v2 1/2] " John Harrison
2024-04-23 9:27 ` Andi Shyti
2024-04-23 9:49 ` ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915: Refactor confusing __intel_gt_reset() (rev2) Patchwork
2024-04-23 9:57 ` ✓ Fi.CI.BAT: success " Patchwork
2024-04-23 10:28 ` ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915: Refactor confusing __intel_gt_reset() Patchwork
2024-04-24 8:16 ` ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915: Refactor confusing __intel_gt_reset() (rev2) Patchwork
2024-04-24 8:56 ` Nirmoy Das
2024-04-24 17:06 ` Andi Shyti
2024-04-24 20:51 ` Das, Nirmoy
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=ZifI63mDmzFkLAJQ@ashyti-mobl2.lan \
--to=andi.shyti@linux.intel.com \
--cc=John.C.Harrison@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=nirmoy.das@intel.com \
--cc=nirmoy.das@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