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: > > 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 <chris@xxxxxxxxxxxxxxxxxx> > > Cc: "Goel, Akash" <akash.goel@xxxxxxxxx> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Cc: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html