Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

2016-10-20 Thread Daniel Vetter
On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote: > > 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

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

2016-10-19 Thread Tahvanainen, Jari
Late Tested-By: Jari Tahvanainen I executed in HSW 100 times a test list having only one prime_vgem test case and vgem_basic@unload. With fix below: 100% pass for vgem_basic@unload Without fix below: 100% skip for vgem_basic@unload During last night I started 100

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

2016-10-18 Thread Petri Latvala
On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote: > vgem doesn't have the same delayed close as i915. For vgem, closing the > fd (i.e. on process exit) will first signal all fences and drop > references for that fd, so effectively all work will be completed. The > external references

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

2016-10-18 Thread Chris Wilson
On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote: > 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)... vgem doesn't

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

2016-10-18 Thread Petri Latvala
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

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

2016-10-18 Thread Chris Wilson
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

[Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

2016-10-18 Thread Petri Latvala
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. When tested on HSW, one 1s sleep wasn't enough, 3s was. Signed-off-by: Petri Latvala