* [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
@ 2018-05-25 15:14 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2018-05-25 15:14 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
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
^ permalink raw reply related [flat|nested] 10+ messages in thread* [igt-dev] ✓ Fi.CI.BAT: success for igt/perf_pmu: Flush to idle after hang
2018-05-25 15:14 ` [igt-dev] " Chris Wilson
(?)
@ 2018-05-25 16:12 ` Patchwork
-1 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2018-05-25 16:12 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
== 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
^ permalink raw reply [flat|nested] 10+ messages in thread* [igt-dev] ✓ Fi.CI.IGT: success for igt/perf_pmu: Flush to idle after hang
2018-05-25 15:14 ` [igt-dev] " Chris Wilson
(?)
(?)
@ 2018-05-26 0:50 ` Patchwork
-1 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2018-05-26 0:50 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev
== 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
2018-05-25 15:14 ` [igt-dev] " Chris Wilson
@ 2018-05-29 20:05 ` Antonio Argenziano
-1 siblings, 0 replies; 10+ messages in thread
From: Antonio Argenziano @ 2018-05-29 20:05 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
@ 2018-05-29 20:05 ` Antonio Argenziano
0 siblings, 0 replies; 10+ messages in thread
From: Antonio Argenziano @ 2018-05-29 20:05 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
2018-05-25 15:14 ` [igt-dev] " Chris Wilson
@ 2018-05-30 10:48 ` Tvrtko Ursulin
-1 siblings, 0 replies; 10+ messages in thread
From: Tvrtko Ursulin @ 2018-05-30 10:48 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [igt-dev] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
@ 2018-05-30 10:48 ` Tvrtko Ursulin
0 siblings, 0 replies; 10+ messages in thread
From: Tvrtko Ursulin @ 2018-05-30 10:48 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: igt-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
2018-05-30 10:48 ` [igt-dev] " Tvrtko Ursulin
@ 2018-05-30 10:57 ` Chris Wilson
-1 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2018-05-30 10:57 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: igt-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [Intel-gfx] [PATCH i-g-t] igt/perf_pmu: Flush to idle after hang
@ 2018-05-30 10:57 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2018-05-30 10:57 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx; +Cc: igt-dev
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
^ permalink raw reply [flat|nested] 10+ messages in thread