From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts
Date: Fri, 10 Nov 2017 14:19:42 +0200 [thread overview]
Message-ID: <87y3neqqap.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20171110112550.28909-1-chris@chris-wilson.co.uk>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> So it appears that commit 5427f207852d ("drm/i915: Bump wait-times for
> the final CS interrupt before parking") was a little over optimistic in
> its belief that it had successfully waited for all residual activity on
> the engines before parking. Numerous sightings in CI since then of
>
> <7>[ 52.542886] [IGT] core_auth: executing
> <3>[ 52.561013] [drm:intel_engines_park [i915]] *ERROR* vcs0 is not idle before parking
> <7>[ 52.561215] intel_engines_park vcs0
> <7>[ 52.561229] intel_engines_park current seqno 98, last 98, hangcheck 0 [-247449 ms], inflight 0
> <7>[ 52.561238] intel_engines_park Reset count: 0
> <7>[ 52.561266] intel_engines_park Requests:
> <7>[ 52.561363] intel_engines_park RING_START: 0x00000000 [0x00000000]
> <7>[ 52.561377] intel_engines_park RING_HEAD: 0x00000000 [0x00000000]
> <7>[ 52.561390] intel_engines_park RING_TAIL: 0x00000000 [0x00000000]
> <7>[ 52.561406] intel_engines_park RING_CTL: 0x00000000
> <7>[ 52.561422] intel_engines_park RING_MODE: 0x00000200 [idle]
> <7>[ 52.561442] intel_engines_park ACTHD: 0x00000000_00000000
> <7>[ 52.561459] intel_engines_park BBADDR: 0x00000000_00000000
> <7>[ 52.561474] intel_engines_park Execlist status: 0x00000301 00000000
> <7>[ 52.561489] intel_engines_park Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no
> <7>[ 52.561500] intel_engines_park ELSP[0] idle
> <7>[ 52.561510] intel_engines_park ELSP[1] idle
> <7>[ 52.561519] intel_engines_park HW active? 0x0
> <7>[ 52.561608] intel_engines_park Idle? yes
> <7>[ 52.561617] intel_engines_park
>
> on Braswell, which indicates that the engine just needs that little bit
> longer after flushing the tasklet to settle. So give it a few more
> milliseconds before declaring an emergency and applying the emergency
> brake.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103479
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 6cb8e3ed97e4..87778f03393b 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1626,11 +1626,12 @@ void intel_engines_park(struct drm_i915_private *i915)
> * will be no more interrupts arriving later and the engines
> * are truly idle.
> */
> - if (!intel_engine_is_idle(engine)) {
> + if (wait_for(intel_engine_is_idle(engine), 10)) {
> struct drm_printer p = drm_debug_printer(__func__);
>
> - DRM_ERROR("%s is not idle before parking\n",
> - engine->name);
> + dev_err(i915->drm.dev,
> + "%s is not idle before parking\n",
> + engine->name);
> intel_engine_dump(engine, &p);
> }
>
> --
> 2.15.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-11-10 12:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 11:25 [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts Chris Wilson
2017-11-10 11:54 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-11-10 12:00 ` [PATCH] " Mika Kuoppala
2017-11-10 12:06 ` Chris Wilson
2017-11-10 12:12 ` Chris Wilson
2017-11-10 12:19 ` Mika Kuoppala [this message]
2017-11-10 13:02 ` Chris Wilson
2017-11-10 12:36 ` ✓ Fi.CI.IGT: success for " 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=87y3neqqap.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.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.