On Wed, Jan 27, 2016 at 02:27:20PM +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) > > Cc: John Harrison <John.C.Harrison@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx> > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c > index 6f5b511..c661dfe 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev, > return ret; > } > > + // if we don't hold a wakeref the I/O access can fail /* C-style comments only */ /* Access through the GTT requires the device to be awake. */ > + assert_rpm_wakelock_held(dev_priv); Now if we could just add intel_runtime_pm_get_noresume() here and add intel_runtime_pm_put() to unpin to indicate the range of the access, that would be ideal. However, that requires us to be more proactive in dropping the context pin. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
