On Wed, Aug 26, 2015 at 03:06:59PM +0200, Daniel Vetter wrote:

On Wed, Aug 26, 2015 at 12:55:57PM +0100, Chris Wilson wrote:

quoted

As we mark the preallocated objects as bound, we should also flag them
correctly as being map-and-fenceable (if appropriate!) so that latter
users do not get confused and try and rebind the pinned vma in order to
get a map-and-fenceable binding.

Signed-off-by: Chris Wilson <redacted>
Cc: "Goel, Akash" <redacted>
Cc: Daniel Vetter <redacted>
Cc: Jesse Barnes <redacted>
Cc: stable@vger.kernel.org

Reviewed-by: Daniel Vetter <redacted>

Jani, can you please pick up both? And some bugzilla references for either
would be great too - Chris?

There's a few candidate "overwrite of address 0" bugs, but no way to
really tell if that is the fbcon or userspace without trial and error.
 

Oh and does patch 1 fix the execlist resume troubles? Execlist having
bigger contexts might be enough explanations for the apparent regression.

Hmm, plausible.
 

And can we igt patch 1 somehow? E.g. with memory pressure plus doing an
mmap on the legacy fbdev ...

Look at i915_gem_framebuffer for the fbcon gtt address before/after
aperture thrashing. Would also need to switch to a user framebuffer to
drop the scanout pinning.

Or just assert that it is still pinned following a modeset away from
fbcon.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre