| Message ID | 1372710870-4329-1-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > Every other place properly checks whether we've managed to set > up the stolen allocator at boot-up properly, with the exception > of the cleanup code. Which results in an ugly > > *ERROR* Memory manager not clean. Delaying takedown > > at module unload time since the drm_mm isn't initialized at all. > > v2: While at it check whether the stolen drm_mm is initialized instead > of the more obscure stolen_base == 0 check. > > v3: Fix up the logic. Also we need to keep the stolen_base check in > i915_gem_object_create_stolen_for_preallocated since that can be > called before stolen memory is fully set up. Spotted by Chris Wilson. Can you grab a backtrace for stolen_base && !initialized(stolen)? Since preallocated touches the stolen mm, it should be setup by that point. -Chris
On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > > Every other place properly checks whether we've managed to set > > up the stolen allocator at boot-up properly, with the exception > > of the cleanup code. Which results in an ugly > > > > *ERROR* Memory manager not clean. Delaying takedown > > > > at module unload time since the drm_mm isn't initialized at all. > > > > v2: While at it check whether the stolen drm_mm is initialized instead > > of the more obscure stolen_base == 0 check. > > > > v3: Fix up the logic. Also we need to keep the stolen_base check in > > i915_gem_object_create_stolen_for_preallocated since that can be > > called before stolen memory is fully set up. Spotted by Chris Wilson. > > Can you grab a backtrace for stolen_base && !initialized(stolen)? Since > preallocated touches the stolen mm, it should be setup by that point. I haven't seen it blow up at runtime, but we have special code in i915_gem_object_create_stolen_for_preallocated which handles the !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow us to wrap the vbios framebuffer. Hm, on that notion I wonder whether we should keep the display up while doing a module reload - it would be a neat exercise for all that fastboot state reconstruction code. Especially the fb reconstruction code would get much more pacing than what it gets now (since grub tends to leave the display in VGA mode so often ...). -Daniel
On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > Every other place properly checks whether we've managed to set > up the stolen allocator at boot-up properly, with the exception > of the cleanup code. Which results in an ugly > > *ERROR* Memory manager not clean. Delaying takedown > > at module unload time since the drm_mm isn't initialized at all. > > v2: While at it check whether the stolen drm_mm is initialized instead > of the more obscure stolen_base == 0 check. > > v3: Fix up the logic. Also we need to keep the stolen_base check in > i915_gem_object_create_stolen_for_preallocated since that can be > called before stolen memory is fully set up. Spotted by Chris Wilson. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953 > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: lu hua <huax.lu@intel.com> > --- > drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c > index 8e02344..fbfc2c7 100644 > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c > @@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device *dev, int size) > { > struct drm_i915_private *dev_priv = dev->dev_private; > > - if (dev_priv->mm.stolen_base == 0) > + if (!drm_mm_initialized(&dev_priv->mm.stolen)) > return -ENODEV; > > if (size < dev_priv->fbc.size) > @@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev) > { > struct drm_i915_private *dev_priv = dev->dev_private; > > + if (!drm_mm_initialized(&dev_priv->mm.stolen)) > + return; > + > i915_gem_stolen_cleanup_compression(dev); > drm_mm_takedown(&dev_priv->mm.stolen); > } > @@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size) > struct drm_i915_gem_object *obj; > struct drm_mm_node *stolen; > > - if (dev_priv->mm.stolen_base == 0) > + if (!drm_mm_initialized(&dev_priv->mm.stolen)) > return NULL; > > DRM_DEBUG_KMS("creating stolen object: size=%x\n", size); > -- > 1.8.3.1 >
On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote: > On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: > > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > > > Every other place properly checks whether we've managed to set > > > up the stolen allocator at boot-up properly, with the exception > > > of the cleanup code. Which results in an ugly > > > > > > *ERROR* Memory manager not clean. Delaying takedown > > > > > > at module unload time since the drm_mm isn't initialized at all. > > > > > > v2: While at it check whether the stolen drm_mm is initialized instead > > > of the more obscure stolen_base == 0 check. > > > > > > v3: Fix up the logic. Also we need to keep the stolen_base check in > > > i915_gem_object_create_stolen_for_preallocated since that can be > > > called before stolen memory is fully set up. Spotted by Chris Wilson. > > > > Can you grab a backtrace for stolen_base && !initialized(stolen)? Since > > preallocated touches the stolen mm, it should be setup by that point. > > I haven't seen it blow up at runtime, but we have special code in > i915_gem_object_create_stolen_for_preallocated which handles the > !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow > us to wrap the vbios framebuffer. That's a different drm_mm for the ggtt. We still need the stolen mm setup in order to allocate our memory (as we don't have the same dance to reconstruct the reserved blocks upon initialisation of stolen). > Hm, on that notion I wonder whether we should keep the display up while > doing a module reload - it would be a neat exercise for all that fastboot > state reconstruction code. Especially the fb reconstruction code would get > much more pacing than what it gets now (since grub tends to leave the > display in VGA mode so often ...). Yes. -Chris
On Tue, Jul 02, 2013 at 09:13:34AM +0100, Chris Wilson wrote: > On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote: > > On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: > > > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > > > > Every other place properly checks whether we've managed to set > > > > up the stolen allocator at boot-up properly, with the exception > > > > of the cleanup code. Which results in an ugly > > > > > > > > *ERROR* Memory manager not clean. Delaying takedown > > > > > > > > at module unload time since the drm_mm isn't initialized at all. > > > > > > > > v2: While at it check whether the stolen drm_mm is initialized instead > > > > of the more obscure stolen_base == 0 check. > > > > > > > > v3: Fix up the logic. Also we need to keep the stolen_base check in > > > > i915_gem_object_create_stolen_for_preallocated since that can be > > > > called before stolen memory is fully set up. Spotted by Chris Wilson. > > > > > > Can you grab a backtrace for stolen_base && !initialized(stolen)? Since > > > preallocated touches the stolen mm, it should be setup by that point. > > > > I haven't seen it blow up at runtime, but we have special code in > > i915_gem_object_create_stolen_for_preallocated which handles the > > !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow > > us to wrap the vbios framebuffer. > > That's a different drm_mm for the ggtt. We still need the stolen mm setup > in order to allocate our memory (as we don't have the same dance to > reconstruct the reserved blocks upon initialisation of stolen). Oh right, I'll update the patch. -Daniel
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index 8e02344..fbfc2c7 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -147,7 +147,7 @@ int i915_gem_stolen_setup_compression(struct drm_device *dev, int size) { struct drm_i915_private *dev_priv = dev->dev_private; - if (dev_priv->mm.stolen_base == 0) + if (!drm_mm_initialized(&dev_priv->mm.stolen)) return -ENODEV; if (size < dev_priv->fbc.size) @@ -179,6 +179,9 @@ void i915_gem_cleanup_stolen(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; + if (!drm_mm_initialized(&dev_priv->mm.stolen)) + return; + i915_gem_stolen_cleanup_compression(dev); drm_mm_takedown(&dev_priv->mm.stolen); } @@ -300,7 +303,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 size) struct drm_i915_gem_object *obj; struct drm_mm_node *stolen; - if (dev_priv->mm.stolen_base == 0) + if (!drm_mm_initialized(&dev_priv->mm.stolen)) return NULL; DRM_DEBUG_KMS("creating stolen object: size=%x\n", size);
Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown at module unload time since the drm_mm isn't initialized at all. v2: While at it check whether the stolen drm_mm is initialized instead of the more obscure stolen_base == 0 check. v3: Fix up the logic. Also we need to keep the stolen_base check in i915_gem_object_create_stolen_for_preallocated since that can be called before stolen memory is fully set up. Spotted by Chris Wilson. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65953 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/i915_gem_stolen.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)