On 10/18/2016 02:36 PM, Chris Wilson wrote:
On Tue, Oct 18, 2016 at 02:25:21PM +0300, Petri Latvala wrote:
If executed too soon after prime_vgem tests, the vgem unload test
fails due to its execbuffers still being handled in the kernel. Retry
the unload three times with sleeps before reporting a skip.
What happened to igt ensuring that the driver was idle before closing a
test? I guess that is complicated by the use of multiple drivers in
vgem.
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 40bbff6..5d3aaa8 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -344,14 +344,18 @@ int drm_open_driver(int chipset)
fd = __drm_open_driver(chipset);
igt_skip_on_f(fd<0, "No known gpu found\n");
- if (__sync_fetch_and_add(&open_count, 1))
- return fd;
-
+ /* For i915, at least, we ensure that the driver is idle before
+ * starting a test and we install an exit handler to wait until
+ * idle before quitting.
+ */
if (is_i915_device(fd)) {
- gem_quiescent_gpu(fd);
- igt_install_exit_handler(quiescent_gpu_at_exit);
+ if (__sync_fetch_and_add(&open_count, 1) == 0) {
+ gem_quiescent_gpu(fd);
+
+ at_exit_drm_fd = __drm_open_driver(chipset);
+ igt_install_exit_handler(quiescent_gpu_at_exit);
+ }
}
- at_exit_drm_fd = __drm_open_driver(chipset);
return fd;
}
Well I'll be damned, that's an obvious bugfix, regardless of its effects
on vgem unload. Please push that with a descriptive commit message and
Reviewed-by: Petri Latvala <petri.latv...@intel.com>.
How should vgem work be flushed properly? With this i915 flushing is
guaranteed even if vgem is opened first, then i915, but such flushing
won't be done if only vgem is opened (I see only vgem_slow doing that)...
Jari will soon reply about vgem unload with this change applied.
--
Petri Latvala
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
