On Thu, Dec 5, 2013 at 3:28 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Tue, Oct 22, 2013 at 2:04 PM, Siluvery, Arun <arun.siluvery@xxxxxxxxx> wrote: >> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c >> index e7b39d7..927a27b 100644 >> --- a/drivers/gpu/drm/i915/i915_gem.c >> +++ b/drivers/gpu/drm/i915/i915_gem.c >> @@ -3275,6 +3275,10 @@ search_free: >> obj->cache_level, >> map_and_fenceable, >> nonblocking); >> + >> + if (ret == -ENOSPC) >> + ret = i915_gem_evict_everything(dev); >> + > > Despite my earlier claim this is indeed a real bugfix - compared to > evict_something this will move away any hw context objects. So this > isn't just purely duct-tape. > > I think the right approach for this patch would be to create a > i915_gem_evict_unpin_special_objects function or similar which atm > just does the do_switch to the default context. We can then call this > here and in evict_everything. > > Can you please look into that and test whether that helps as well as > your current hack? > > I've noticed this while trying to create a testcase for the recently > fought do_switch eviction related oops. I just couldn't and that got > me thinking a bit ;-) Fyi I've just pushed out igt/gem_ctx_exec/eviction which exercises our current failure to evict the current contxt. It's going through execbuf though and doesn't test the gtt mmap path. Fixing up that is imo only worth it as part of the large plan I've outlined somewhere else in this thread. Atm the test fails, but it should work with proper context eviction. So this should be useful for a more minimal testcase. Since the testcase starts with a too-big execbuf that should also exercise the endless loop you've outlined in the internal mail, but I think for safety we want to add one more execbuf call in the eviction test with a 3rd context and just 1 buffer too much in the reloc list. That should perfectly reproduce your failure case. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
