On 10/08/18 10:51, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-10 18:41:22)
On 10/08/18 04:01, Chris Wilson wrote:
Normally we wait on the last request, but that overlooks any
difficulties in waiting on a request while the next is being qeued.
/s/qeued/queued
Check those.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
tests/gem_sync.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index c697220ad..fb209977d 100644
--- a/tests/gem_sync.c
+++ b/tests/gem_sync.c
@@ -294,6 +294,74 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
}
+ intel_detect_and_clear_missed_interrupts(fd);
+ igt_fork(child, num_engines) {
+ double start, end, elapsed;
+ unsigned long cycles;
+ igt_spin_t *spin[2];
+ uint32_t cmd;
+
+ spin[0] = __igt_spin_batch_new(fd,
+ .engine = ring,
+ .flags = IGT_SPIN_FAST);
+ cmd = *spin[0]->batch;
+
+ spin[1] = __igt_spin_batch_new(fd,
+ .engine = ring,
+ .flags = IGT_SPIN_FAST);
+ igt_assert(*spin[1]->batch == cmd);
+
+ start = gettime();
+ end = start + timeout;
+ cycles = 0;
+ do {
+ for (int loop = 0; loop < 1024; loop++) {
+ igt_spin_t *s = spin[loop & 1];
+
+ igt_spin_batch_end(s);
+ gem_sync(fd, s->handle);
How does the test fail if the sync goes wrong? Hang detector on the
queued batch?
We have a hang detector for both missed wakeups and GPU hangs. As tests
goes it's fairly tame, but in essence this entire file is about trying
to trick the HW+driver into not sending an interrupt back to userspace.
Just a very narrow stress test, over and over again from slightly
different angles.
I see.
Reviewed-by: Antonio Argenziano <antonio.argenziano@xxxxxxxxx>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
