For details see https://bugs.chromium.org/p/chromium/issues/detail?id=468050 So drm_mode_config_cleanup() is called from udl_driver_unload() in which we found there's still a framebuffer left, hence the WARN in drm_crtc.c:5495. This also forcefully releases all the buffers. A bit later the actual drm_buf_release comes in which attempts to release the buffer again. On Wed, Aug 31, 2016 at 12:55 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Tue, Aug 30, 2016 at 02:50:20PM -0700, Haixia Shi wrote: > > Previously this function had a NULL pointer check for gem->map_list.map, but > > that line was refactored after commit 0de23977cfeb5b357ec884ba15417ae118ff9e9bb > > ("drm/gem: convert to new unified vma manager"). > > > > After the refactor it is still necessasry to check that the vma manager is not > > NULL because udl_gem_free_object() may come in after the vma manager is destroyed. > > When/how does this happen? Backtrace? Destroying the vma manager before > the objects are all gone sounds a bit fishy. > -Daniel > > > > > Signed-off-by: Haixia Shi <hshi@xxxxxxxxxxxx> > > Reviewed-by: Stéphane Marchesin <marcheu@xxxxxxxxxxxx> > > --- > > drivers/gpu/drm/udl/udl_gem.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c > > index 818e707..72e1bd4 100644 > > --- a/drivers/gpu/drm/udl/udl_gem.c > > +++ b/drivers/gpu/drm/udl/udl_gem.c > > @@ -204,7 +204,8 @@ void udl_gem_free_object(struct drm_gem_object *gem_obj) > > if (obj->pages) > > udl_gem_put_pages(obj); > > > > - drm_gem_free_mmap_offset(gem_obj); > > + if (gem_obj->dev->vma_offset_manager) > > + drm_gem_free_mmap_offset(gem_obj); > > } > > > > /* the dumb interface doesn't work with the GEM straight MMAP > > -- > > 2.8.0.rc3.226.g39d4020 > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
