On Wed, Jan 27, 2016 at 04:44:37PM +0000, Chris Wilson wrote: > On Wed, Jan 27, 2016 at 03:43:49PM +0000, daniele.ceraolospurio@xxxxxxxxx wrote: > > From: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > > > > While running some tests on the scheduler patches with rpm enabled I > > came across a corruption in the ringbuffer, which was root-caused to > > the GPU being suspended while commands were being emitted to the > > ringbuffer. The access to memory was failing because the GPU needs to > > be awake when accessing stolen memory (where my ringbuffer was located). > > Since we have this constraint it looks like a sensible idea to check > > that we hold a refcount when we access the rungbuffer. > > > > v2: move the check from ring_begin to ringbuffer iomap time (Chris) > > v3: update comment (Chris) > > > > Cc: John Harrison <John.C.Harrison@xxxxxxxxx> > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > > That explains itself nicely, thanks. > Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Queued for -next, thanks for the patch. > It also rings alarms bells for intel_fbdev.c Oops, indeed. Might explain why we sometimes just die? And fundamentally it's unfixable (without a shadow fb) since we can't intercept mmaps on fbdev. But maybe we need to do that (and use the damage tracking that's already there in 3 copies in various drivers for uploading). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
