All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Exclude low pages (128KiB) of stolen from use
Date: Thu, 8 Oct 2020 13:24:06 +0300	[thread overview]
Message-ID: <20201008102406.GJ6112@intel.com> (raw)
In-Reply-To: <160215195782.27361.8014008642581322158@build.alporthouse.com>

On Thu, Oct 08, 2020 at 11:12:37AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2020-10-08 11:04:22)
> > On Thu, Oct 08, 2020 at 10:54:36AM +0100, Chris Wilson wrote:
> > > The GPU is trashing the low pages of its reserved memory upon reset. If
> > > we are using this memory for ringbuffers, then we will dutiful resubmit
> > > the trashed rings after the reset causing further resets, and worse. We
> > > must exclude this range from our own use. The value of 128KiB was found
> > > by empirical measurement on gen9.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: stable@vger.kernel.org
> > > ---
> > > v2 comes with a selftest to see how widespread the issue is
> > 
> > Do we need something to make sure FBC isn't scribbling into
> > stolen during the test?
> 
> igt runs the tests with disable_display=1, that is still being honoured
> right?

It just marks all connectors as disconnected now. If coming straight
from boot presumaly whatever the BIOS lit up could still be on at that
point. Though I guess we would have typically done a module reload
for this? rmmod should shut things down IIRC. Also wouldn't think the
BIOS would even enables FBC.

> 
> I did think about looking up the address to see if the drm_mm_node is in
> use to try and filter out such users. For starters, I just want to
> confirm that CI is seeing what I'm seeing.
> -Chris

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Exclude low pages (128KiB) of stolen from use
Date: Thu, 8 Oct 2020 13:24:06 +0300	[thread overview]
Message-ID: <20201008102406.GJ6112@intel.com> (raw)
In-Reply-To: <160215195782.27361.8014008642581322158@build.alporthouse.com>

On Thu, Oct 08, 2020 at 11:12:37AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2020-10-08 11:04:22)
> > On Thu, Oct 08, 2020 at 10:54:36AM +0100, Chris Wilson wrote:
> > > The GPU is trashing the low pages of its reserved memory upon reset. If
> > > we are using this memory for ringbuffers, then we will dutiful resubmit
> > > the trashed rings after the reset causing further resets, and worse. We
> > > must exclude this range from our own use. The value of 128KiB was found
> > > by empirical measurement on gen9.
> > > 
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: stable@vger.kernel.org
> > > ---
> > > v2 comes with a selftest to see how widespread the issue is
> > 
> > Do we need something to make sure FBC isn't scribbling into
> > stolen during the test?
> 
> igt runs the tests with disable_display=1, that is still being honoured
> right?

It just marks all connectors as disconnected now. If coming straight
from boot presumaly whatever the BIOS lit up could still be on at that
point. Though I guess we would have typically done a module reload
for this? rmmod should shut things down IIRC. Also wouldn't think the
BIOS would even enables FBC.

> 
> I did think about looking up the address to see if the drm_mm_node is in
> use to try and filter out such users. For starters, I just want to
> confirm that CI is seeing what I'm seeing.
> -Chris

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2020-10-08 10:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08  9:54 [Intel-gfx] [PATCH v2] drm/i915: Exclude low pages (128KiB) of stolen from use Chris Wilson
2020-10-08  9:54 ` Chris Wilson
2020-10-08 10:04 ` [Intel-gfx] " Ville Syrjälä
2020-10-08 10:04   ` Ville Syrjälä
2020-10-08 10:12   ` Chris Wilson
2020-10-08 10:24     ` Ville Syrjälä [this message]
2020-10-08 10:24       ` Ville Syrjälä
2020-10-08 12:06 ` [Intel-gfx] [PATCH v3] " Chris Wilson
2020-10-08 12:06   ` Chris Wilson
2020-10-08 15:44 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Exclude low pages (128KiB) of stolen from use (rev3) Patchwork
2020-10-08 15:45 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-10-08 16:13 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=20201008102406.GJ6112@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stable@vger.kernel.org \
    /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.