| Message ID | 1347698517-4875-1-git-send-email-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Sat, Sep 15, 2012 at 09:41:57AM +0100, Chris Wilson wrote: > Pin-leaks persist and we get the perennial bug reports of machine > lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that > the object cannot be pinned at that time it should prevent the driver from > locking up, and hopefully restore a semblance of working whilst still > leaving us a OOPS to debug. > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Picked up for -fixes, thanks for the patch. wrt pin leaks, I think all the ones we still have are worker thread starvations, combined with irqs firing too fast. /should/ be fixable ... -Daniel > --- > drivers/gpu/drm/i915/i915_gem.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index da17b40..58a5f6a 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3555,7 +3555,8 @@ i915_gem_object_pin(struct drm_i915_gem_object *obj, > { > int ret; > > - BUG_ON(obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT); > + if (WARN_ON(obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)) > + return -EBUSY; > > if (obj->gtt_space != NULL) { > if ((alignment && obj->gtt_offset & (alignment - 1)) || > -- > 1.7.10.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 17 Sep 2012 09:48:24 +0200, Daniel Vetter <daniel@ffwll.ch> wrote: > On Sat, Sep 15, 2012 at 09:41:57AM +0100, Chris Wilson wrote: > > Pin-leaks persist and we get the perennial bug reports of machine > > lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that > > the object cannot be pinned at that time it should prevent the driver from > > locking up, and hopefully restore a semblance of working whilst still > > leaving us a OOPS to debug. > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Picked up for -fixes, thanks for the patch. wrt pin leaks, I think all the > ones we still have are worker thread starvations, combined with irqs > firing too fast. /should/ be fixable ... Right, the latest are in association with pageflipping so that's a plausible cause. Otoh, we also appear to have a multiple unpin somewhere in the reset code - which might very well be related. Hmm. -Chris
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index da17b40..58a5f6a 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3555,7 +3555,8 @@ i915_gem_object_pin(struct drm_i915_gem_object *obj, { int ret; - BUG_ON(obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT); + if (WARN_ON(obj->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)) + return -EBUSY; if (obj->gtt_space != NULL) { if ((alignment && obj->gtt_offset & (alignment - 1)) ||
Pin-leaks persist and we get the perennial bug reports of machine lockups to the BUG_ON(pin_count==MAX). If we instead loudly report that the object cannot be pinned at that time it should prevent the driver from locking up, and hopefully restore a semblance of working whilst still leaving us a OOPS to debug. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)