[PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

[PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

[Chris Wilson]

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>
---
 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

✓ Fi.CI.BAT: success for drm/i915: Restore the wait for idle engine after flushing interrupts

[Patchwork]

== Series Details ==

Series: drm/i915: Restore the wait for idle engine after flushing interrupts
URL   : https://patchwork.freedesktop.org/series/33593/
State : success

== Summary ==

Series 33593v1 drm/i915: Restore the wait for idle engine after flushing interrupts
https://patchwork.freedesktop.org/api/1.0/series/33593/revisions/1/mbox/

Test chamelium:
        Subgroup dp-crc-fast:
                pass       -> FAIL       (fi-kbl-7500u) fdo#102514
Test gem_exec_reloc:
        Subgroup basic-gtt-cpu-active:
                fail       -> PASS       (fi-gdg-551) fdo#102582 +3
        Subgroup basic-write-cpu-active:
                fail       -> PASS       (fi-gdg-551) fdo#102582 +1
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-c:
                pass       -> INCOMPLETE (fi-kbl-7560u) fdo#102846

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582
fdo#102582 https://bugs.freedesktop.org/show_bug.cgi?id=102582
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:441s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:460s
fi-blb-e6850     total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:380s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:546s
fi-bwr-2160      total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 time:273s
fi-bxt-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:499s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:499s
fi-byt-j1900     total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  time:492s
fi-byt-n2820     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:484s
fi-elk-e7500     total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:431s
fi-gdg-551       total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 time:264s
fi-glk-1         total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:537s
fi-hsw-4770      total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:427s
fi-hsw-4770r     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:444s
fi-ilk-650       total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  time:425s
fi-ivb-3520m     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:479s
fi-ivb-3770      total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:475s
fi-kbl-7500u     total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  time:480s
fi-kbl-7560u     total:247  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-kbl-7567u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:468s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:534s
fi-pnv-d510      total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  time:578s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:452s
fi-skl-6600u     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:543s
fi-skl-6700hq    total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:566s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:510s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:458s
fi-snb-2520m     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:561s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  time:419s
Blacklisted hosts:
fi-cfl-s         total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  time:532s
fi-cnl-y         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:583s
fi-glk-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:490s

831ae3962a169aa94457f1c7742dd3591b394f70 drm-tip: 2017y-11m-09d-23h-29m-57s UTC integration manifest
adb5e40d34e3 drm/i915: Restore the wait for idle engine after flushing interrupts

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7055/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

[Mika Kuoppala]

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.
>

Because the print above indicates that it did went idle straight
afterwards?

Just pondering here what was the key nonidleness key that
lead to this. What raced?

-Mika


> 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>
> ---
>  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

Re: [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

[Chris Wilson]

Quoting Mika Kuoppala (2017-11-10 12:00:38)
> 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.
> >
> 
> Because the print above indicates that it did went idle straight
> afterwards?

Indeed.
 
> Just pondering here what was the key nonidleness key that
> lead to this. What raced?

Still pondering myself. This is basically to shut CI up so the random
fails stop inflicting the confusion of false positives.

My guess is that it is a residual ELSP tasklet and the ring registers
taking a moment to idle. But I am not sure, on the way here we gave it
long enough to settle with no new work coming in, so it should not need
another 10ms on top of the 200ms it already had!
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

[Chris Wilson]

Quoting Chris Wilson (2017-11-10 12:06:59)
> Quoting Mika Kuoppala (2017-11-10 12:00:38)
> > Just pondering here what was the key nonidleness key that
> > lead to this. What raced?
> 
> Still pondering myself. This is basically to shut CI up so the random
> fails stop inflicting the confusion of false positives.
> 
> My guess is that it is a residual ELSP tasklet and the ring registers
> taking a moment to idle. But I am not sure, on the way here we gave it
> long enough to settle with no new work coming in, so it should not need
> another 10ms on top of the 200ms it already had!

One thing to note is that it seems limited to that one bsw, and either
vcs or vecs rings. Being slow and under-cored (i.e. scheduler delays)
might just be the explanation. :|
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

[Mika Kuoppala]

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

✓ Fi.CI.IGT: success for drm/i915: Restore the wait for idle engine after flushing interrupts

[Patchwork]

== Series Details ==

Series: drm/i915: Restore the wait for idle engine after flushing interrupts
URL   : https://patchwork.freedesktop.org/series/33593/
State : success

== Summary ==

Test perf:
        Subgroup polling:
                pass       -> FAIL       (shard-hsw) fdo#102252
Test kms_flip:
        Subgroup plain-flip-ts-check:
                pass       -> FAIL       (shard-hsw) fdo#100368
        Subgroup dpms-vs-vblank-race-interruptible:
                pass       -> FAIL       (shard-hsw) fdo#103060
Test kms_setmode:
        Subgroup basic:
                pass       -> FAIL       (shard-hsw) fdo#99912

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hsw        total:2584 pass:1449 dwarn:2   dfail:2   fail:13  skip:1118 time:9310s
Blacklisted hosts:
shard-apl        total:2522 pass:1555 dwarn:3   dfail:1   fail:22  skip:939 time:12622s
shard-kbl        total:2575 pass:1695 dwarn:8   dfail:2   fail:24  skip:845 time:9930s
shard-snb        total:2584 pass:1187 dwarn:1   dfail:2   fail:12  skip:1382 time:7703s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7055/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Restore the wait for idle engine after flushing interrupts

[Chris Wilson]

Quoting Mika Kuoppala (2017-11-10 12:19:42)
> 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>

Pushed to keep CI quiet. If we still get an error here, it will be
interesting (and hopefully the engine state provide a clue). The only
problem is without the constant poking, we're likely to forget the race
here.

Thanks,
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx