[PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Chris Wilson]

We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
---
 tests/perf_pmu.c | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 590e6526b..9af192dd8 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
 
 	/* Check for idle after hang. */
 	if (flags & FLAG_HANG) {
-		/* Sleep for a bit for reset unwind to settle. */
-		usleep(500e3);
-		/*
-		 * Ensure batch was executing before reset, meaning it must be
-		 * idle by now. Unless it did not even manage to start before we
-		 * triggered the reset, in which case the idleness check below
-		 * might fail. The latter is very unlikely since there are two
-		 * sleeps during which it had an opportunity to start.
-		 */
+		gem_quiescent_gpu(gem_fd);
 		igt_assert(!gem_bo_busy(gem_fd, spin->handle));
+
 		val = pmu_read_single(fd);
 		slept = measured_usleep(batch_duration_ns / 1000);
 		val = pmu_read_single(fd) - val;
-- 
2.17.0

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

[igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Chris Wilson]

We may not idle immediately after a hang, and indeed may send a pulse
down the pipeline periodically to become idle. Rather than make a flimsy
assumption about how long we need to sleep before the system idles,
wait for the system to declare itself idle; flushing it to idle in the
process!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
---
 tests/perf_pmu.c | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 590e6526b..9af192dd8 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
 
 	/* Check for idle after hang. */
 	if (flags & FLAG_HANG) {
-		/* Sleep for a bit for reset unwind to settle. */
-		usleep(500e3);
-		/*
-		 * Ensure batch was executing before reset, meaning it must be
-		 * idle by now. Unless it did not even manage to start before we
-		 * triggered the reset, in which case the idleness check below
-		 * might fail. The latter is very unlikely since there are two
-		 * sleeps during which it had an opportunity to start.
-		 */
+		gem_quiescent_gpu(gem_fd);
 		igt_assert(!gem_bo_busy(gem_fd, spin->handle));
+
 		val = pmu_read_single(fd);
 		slept = measured_usleep(batch_duration_ns / 1000);
 		val = pmu_read_single(fd) - val;
-- 
2.17.0

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for igt/perf_pmu: Flush to idle after hang

[Patchwork]

== Series Details ==

Series: igt/perf_pmu: Flush to idle after hang
URL   : https://patchwork.freedesktop.org/series/43784/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4238 -> IGTPW_1402 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/43784/revisions/1/mbox/

== Known issues ==

  Here are the changes found in IGTPW_1402 that come from known issues:

  === IGT changes ===

    ==== Possible fixes ====

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      fi-snb-2520m:       INCOMPLETE (fdo#103713) -> PASS

    
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713


== Participating hosts (44 -> 38) ==

  Missing    (6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 fi-skl-6700hq 


== Build changes ==

    * IGT: IGT_4498 -> IGTPW_1402

  CI_DRM_4238: 2771a5e6347eb63e43fdfc432a9f15ffb55ef209 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1402: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1402/
  IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1402/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.IGT: success for igt/perf_pmu: Flush to idle after hang

[Patchwork]

== Series Details ==

Series: igt/perf_pmu: Flush to idle after hang
URL   : https://patchwork.freedesktop.org/series/43784/
State : success

== Summary ==

= CI Bug Log - changes from IGT_4498_full -> IGTPW_1402_full =

== Summary - WARNING ==

  Minor unknown changes coming with IGTPW_1402_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_1402_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/43784/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in IGTPW_1402_full:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_schedule@deep-render:
      shard-kbl:          PASS -> SKIP

    igt@gem_mocs_settings@mocs-rc6-vebox:
      shard-kbl:          SKIP -> PASS +1

    igt@kms_chv_cursor_fail@pipe-a-256x256-bottom-edge:
      shard-snb:          SKIP -> PASS

    
== Known issues ==

  Here are the changes found in IGTPW_1402_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_selftest@live_evict:
      shard-apl:          PASS -> INCOMPLETE (fdo#103927)

    igt@drv_selftest@live_gtt:
      shard-apl:          PASS -> FAIL (fdo#105347)

    igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
      shard-glk:          PASS -> FAIL (fdo#105454, fdo#106509)

    igt@kms_flip@2x-flip-vs-expired-vblank:
      shard-glk:          PASS -> FAIL (fdo#105363)

    igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
      shard-glk:          PASS -> FAIL (fdo#102887)

    igt@kms_flip_tiling@flip-x-tiled:
      shard-glk:          PASS -> FAIL (fdo#103822, fdo#104724)

    igt@kms_rotation_crc@primary-rotation-180:
      shard-snb:          PASS -> FAIL (fdo#103925, fdo#104724)

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)

    igt@kms_vblank@pipe-c-accuracy-idle:
      shard-glk:          PASS -> FAIL (fdo#102583)

    igt@testdisplay:
      shard-glk:          PASS -> INCOMPLETE (k.org#198133, fdo#103359)

    
    ==== Possible fixes ====

    igt@drv_selftest@live_gtt:
      shard-kbl:          INCOMPLETE (fdo#103665) -> PASS +1
      shard-glk:          INCOMPLETE (k.org#198133, fdo#103359) -> PASS

    igt@gem_ppgtt@blt-vs-render-ctx0:
      shard-kbl:          INCOMPLETE (fdo#103665, fdo#106023) -> PASS

    {igt@kms_available_modes_crc@available_mode_test_crc}:
      shard-apl:          FAIL (fdo#106641) -> PASS

    igt@kms_flip@2x-plain-flip-fb-recreate:
      shard-hsw:          FAIL (fdo#103928) -> PASS

    igt@kms_flip@flip-vs-expired-vblank:
      shard-glk:          FAIL (fdo#102887) -> PASS

    igt@kms_flip@flip-vs-expired-vblank-interruptible:
      shard-glk:          FAIL (fdo#105363, fdo#102887) -> PASS

    igt@kms_flip@plain-flip-fb-recreate:
      shard-glk:          FAIL (fdo#100368) -> PASS

    igt@kms_flip_tiling@flip-to-x-tiled:
      shard-glk:          FAIL (fdo#103822, fdo#104724) -> PASS

    igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
      shard-snb:          FAIL (fdo#103166, fdo#104724) -> PASS

    
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509
  fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * IGT: IGT_4498 -> IGTPW_1402
    * Linux: CI_DRM_4227 -> CI_DRM_4238

  CI_DRM_4227: a8727d3fe03770e4d523468dfbc487dfe01597d3 @ git://anongit.freedesktop.org/gfx-ci/linux
  CI_DRM_4238: 2771a5e6347eb63e43fdfc432a9f15ffb55ef209 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1402: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1402/
  IGT_4498: f9ecb79ad8b02278cfdb5b82495df47061c04f8f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

Re: [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Antonio Argenziano]

On 25/05/18 08:14, Chris Wilson wrote:
> We may not idle immediately after a hang, and indeed may send a pulse
> down the pipeline periodically to become idle. Rather than make a flimsy
> assumption about how long we need to sleep before the system idles,
> wait for the system to declare itself idle; flushing it to idle in the
> process!
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>

LGTM.
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>

> ---
>   tests/perf_pmu.c | 11 ++---------
>   1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> index 590e6526b..9af192dd8 100644
> --- a/tests/perf_pmu.c
> +++ b/tests/perf_pmu.c
> @@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
>   
>   	/* Check for idle after hang. */
>   	if (flags & FLAG_HANG) {
> -		/* Sleep for a bit for reset unwind to settle. */
> -		usleep(500e3);
> -		/*
> -		 * Ensure batch was executing before reset, meaning it must be
> -		 * idle by now. Unless it did not even manage to start before we
> -		 * triggered the reset, in which case the idleness check below
> -		 * might fail. The latter is very unlikely since there are two
> -		 * sleeps during which it had an opportunity to start.
> -		 */
> +		gem_quiescent_gpu(gem_fd);
>   		igt_assert(!gem_bo_busy(gem_fd, spin->handle));
> +
>   		val = pmu_read_single(fd);
>   		slept = measured_usleep(batch_duration_ns / 1000);
>   		val = pmu_read_single(fd) - val;
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Antonio Argenziano]

On 25/05/18 08:14, Chris Wilson wrote:
> We may not idle immediately after a hang, and indeed may send a pulse
> down the pipeline periodically to become idle. Rather than make a flimsy
> assumption about how long we need to sleep before the system idles,
> wait for the system to declare itself idle; flushing it to idle in the
> process!
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>

LGTM.
Reviewed-by: Antonio Argenziano <antonio.argenziano@intel.com>

> ---
>   tests/perf_pmu.c | 11 ++---------
>   1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> index 590e6526b..9af192dd8 100644
> --- a/tests/perf_pmu.c
> +++ b/tests/perf_pmu.c
> @@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
>   
>   	/* Check for idle after hang. */
>   	if (flags & FLAG_HANG) {
> -		/* Sleep for a bit for reset unwind to settle. */
> -		usleep(500e3);
> -		/*
> -		 * Ensure batch was executing before reset, meaning it must be
> -		 * idle by now. Unless it did not even manage to start before we
> -		 * triggered the reset, in which case the idleness check below
> -		 * might fail. The latter is very unlikely since there are two
> -		 * sleeps during which it had an opportunity to start.
> -		 */
> +		gem_quiescent_gpu(gem_fd);
>   		igt_assert(!gem_bo_busy(gem_fd, spin->handle));
> +
>   		val = pmu_read_single(fd);
>   		slept = measured_usleep(batch_duration_ns / 1000);
>   		val = pmu_read_single(fd) - val;
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Tvrtko Ursulin]

On 25/05/2018 16:14, Chris Wilson wrote:
> We may not idle immediately after a hang, and indeed may send a pulse
> down the pipeline periodically to become idle. Rather than make a flimsy
> assumption about how long we need to sleep before the system idles,
> wait for the system to declare itself idle; flushing it to idle in the
> process!
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> ---
>   tests/perf_pmu.c | 11 ++---------
>   1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> index 590e6526b..9af192dd8 100644
> --- a/tests/perf_pmu.c
> +++ b/tests/perf_pmu.c
> @@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
>   
>   	/* Check for idle after hang. */
>   	if (flags & FLAG_HANG) {
> -		/* Sleep for a bit for reset unwind to settle. */
> -		usleep(500e3);
> -		/*
> -		 * Ensure batch was executing before reset, meaning it must be
> -		 * idle by now. Unless it did not even manage to start before we
> -		 * triggered the reset, in which case the idleness check below
> -		 * might fail. The latter is very unlikely since there are two
> -		 * sleeps during which it had an opportunity to start.
> -		 */
> +		gem_quiescent_gpu(gem_fd);
>   		igt_assert(!gem_bo_busy(gem_fd, spin->handle));
> +
>   		val = pmu_read_single(fd);
>   		slept = measured_usleep(batch_duration_ns / 1000);
>   		val = pmu_read_single(fd) - val;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

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

Re: [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Tvrtko Ursulin]

On 25/05/2018 16:14, Chris Wilson wrote:
> We may not idle immediately after a hang, and indeed may send a pulse
> down the pipeline periodically to become idle. Rather than make a flimsy
> assumption about how long we need to sleep before the system idles,
> wait for the system to declare itself idle; flushing it to idle in the
> process!
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> ---
>   tests/perf_pmu.c | 11 ++---------
>   1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> index 590e6526b..9af192dd8 100644
> --- a/tests/perf_pmu.c
> +++ b/tests/perf_pmu.c
> @@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
>   
>   	/* Check for idle after hang. */
>   	if (flags & FLAG_HANG) {
> -		/* Sleep for a bit for reset unwind to settle. */
> -		usleep(500e3);
> -		/*
> -		 * Ensure batch was executing before reset, meaning it must be
> -		 * idle by now. Unless it did not even manage to start before we
> -		 * triggered the reset, in which case the idleness check below
> -		 * might fail. The latter is very unlikely since there are two
> -		 * sleeps during which it had an opportunity to start.
> -		 */
> +		gem_quiescent_gpu(gem_fd);
>   		igt_assert(!gem_bo_busy(gem_fd, spin->handle));
> +
>   		val = pmu_read_single(fd);
>   		slept = measured_usleep(batch_duration_ns / 1000);
>   		val = pmu_read_single(fd) - val;
> 

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-30 11:48:16)
> 
> On 25/05/2018 16:14, Chris Wilson wrote:
> > We may not idle immediately after a hang, and indeed may send a pulse
> > down the pipeline periodically to become idle. Rather than make a flimsy
> > assumption about how long we need to sleep before the system idles,
> > wait for the system to declare itself idle; flushing it to idle in the
> > process!
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > ---
> >   tests/perf_pmu.c | 11 ++---------
> >   1 file changed, 2 insertions(+), 9 deletions(-)
> > 
> > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> > index 590e6526b..9af192dd8 100644
> > --- a/tests/perf_pmu.c
> > +++ b/tests/perf_pmu.c
> > @@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
> >   
> >       /* Check for idle after hang. */
> >       if (flags & FLAG_HANG) {
> > -             /* Sleep for a bit for reset unwind to settle. */
> > -             usleep(500e3);
> > -             /*
> > -              * Ensure batch was executing before reset, meaning it must be
> > -              * idle by now. Unless it did not even manage to start before we
> > -              * triggered the reset, in which case the idleness check below
> > -              * might fail. The latter is very unlikely since there are two
> > -              * sleeps during which it had an opportunity to start.
> > -              */
> > +             gem_quiescent_gpu(gem_fd);
> >               igt_assert(!gem_bo_busy(gem_fd, spin->handle));
> > +
> >               val = pmu_read_single(fd);
> >               slept = measured_usleep(batch_duration_ns / 1000);
> >               val = pmu_read_single(fd) - val;
> > 
> 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

That's a relief. I was fearing you might argue that we need some sort of
check that it does idle in a timely fashion without intervention. Off
the top of my head, we do have some gem_wait/gem_eio checks that should
cover that.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-05-30 11:48:16)
> 
> On 25/05/2018 16:14, Chris Wilson wrote:
> > We may not idle immediately after a hang, and indeed may send a pulse
> > down the pipeline periodically to become idle. Rather than make a flimsy
> > assumption about how long we need to sleep before the system idles,
> > wait for the system to declare itself idle; flushing it to idle in the
> > process!
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > ---
> >   tests/perf_pmu.c | 11 ++---------
> >   1 file changed, 2 insertions(+), 9 deletions(-)
> > 
> > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> > index 590e6526b..9af192dd8 100644
> > --- a/tests/perf_pmu.c
> > +++ b/tests/perf_pmu.c
> > @@ -281,16 +281,9 @@ single(int gem_fd, const struct intel_execution_engine2 *e, unsigned int flags)
> >   
> >       /* Check for idle after hang. */
> >       if (flags & FLAG_HANG) {
> > -             /* Sleep for a bit for reset unwind to settle. */
> > -             usleep(500e3);
> > -             /*
> > -              * Ensure batch was executing before reset, meaning it must be
> > -              * idle by now. Unless it did not even manage to start before we
> > -              * triggered the reset, in which case the idleness check below
> > -              * might fail. The latter is very unlikely since there are two
> > -              * sleeps during which it had an opportunity to start.
> > -              */
> > +             gem_quiescent_gpu(gem_fd);
> >               igt_assert(!gem_bo_busy(gem_fd, spin->handle));
> > +
> >               val = pmu_read_single(fd);
> >               slept = measured_usleep(batch_duration_ns / 1000);
> >               val = pmu_read_single(fd) - val;
> > 
> 
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

That's a relief. I was fearing you might argue that we need some sort of
check that it does idle in a timely fashion without intervention. Off
the top of my head, we do have some gem_wait/gem_eio checks that should
cover that.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx