search for: drm_framebuffer_remov

...re left behind. There's a bunch of options: > > - nouveau somehow manages to keep the crtc on without a framebuffer > > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > > - something else > > Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). > If I add that, the crtc gets properly disabled on unload. > > It does call drm_framebuffer_cleanup(). That's why there was no WARN, > drm_mode_config_cleanup() only WARNs if a framebuffer was left on the > mode_config.fb_list. > > radeon and amdgpu have the same pro...

...t; > > > - nouveau somehow manages to keep the crtc on without a framebuffer > > > > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > > > > - something else > > > > > > Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). > > > If I add that, the crtc gets properly disabled on unload. > > > > > > It does call drm_framebuffer_cleanup(). That's why there was no WARN, > > > drm_mode_config_cleanup() only WARNs if a framebuffer was left on the > > > mode_config.fb_li...

...;s a bunch of options: > > > - nouveau somehow manages to keep the crtc on without a framebuffer > > > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > > > - something else > > > > Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). > > If I add that, the crtc gets properly disabled on unload. > > > > It does call drm_framebuffer_cleanup(). That's why there was no WARN, > > drm_mode_config_cleanup() only WARNs if a framebuffer was left on the > > mode_config.fb_list. > > > >...

On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: >> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM >> > core does not turn off the crtc first and neither do the drivers. With

...ON if > framebuffers are left behind. There's a bunch of options: > - nouveau somehow manages to keep the crtc on without a framebuffer > - nouveau somehow leaks a drm_framebuffer, but removes it from the fb_list > - something else Found it. nouveau_fbcon_destroy() doesn't call drm_framebuffer_remove(). If I add that, the crtc gets properly disabled on unload. It does call drm_framebuffer_cleanup(). That's why there was no WARN, drm_mode_config_cleanup() only WARNs if a framebuffer was left on the mode_config.fb_list. radeon and amdgpu have the same problem. In fact there are very few dr...

...o_destroy; > } > > - fb = &fbdev_cma->fb->fb; > + fb = fbdev_cma->fb; > helper->fb = fb; > > fbi->par = helper; > @@ -500,7 +474,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper, > return 0; > > err_cma_destroy: > - drm_framebuffer_remove(&fbdev_cma->fb->fb); > + drm_framebuffer_remove(fbdev_cma->fb); > err_fb_info_destroy: > drm_fb_helper_fini(helper); > err_gem_free_object: > @@ -598,7 +572,7 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma) > drm_fbdev_cma_defio_fini(fbdev_cma-...

...tfb ioctl drm: fb refcounting for dirtyfb_ioctl drm: refcounting for sprite framebuffers drm: encapsulate crtc->set_config calls drm: refcounting for crtc framebuffers drm/i915: dump refcount into framebuffer debugfs file drm/vmwgfx: add proper framebuffer refcounting drm: optimize drm_framebuffer_remove drm/nouveau: try to protect nbo->pin_refcount drm/ttm: fix fence locking in ttm_buffer_object_transfer drm/radeon: fix fence locking in the pageflip callback drm: only grab the crtc lock for pageflips drm: don't hold crtc mutexes for connector ->detect callbacks Documentation...

...rm_fbdev_cma_create(struct drm_fb_helper *helper, goto err_fb_info_destroy; } - fb = &fbdev_cma->fb->fb; + fb = fbdev_cma->fb; helper->fb = fb; fbi->par = helper; @@ -500,7 +474,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper, return 0; err_cma_destroy: - drm_framebuffer_remove(&fbdev_cma->fb->fb); + drm_framebuffer_remove(fbdev_cma->fb); err_fb_info_destroy: drm_fb_helper_fini(helper); err_gem_free_object: @@ -598,7 +572,7 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma) drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev); if (fbde...

...rm_fbdev_cma_create(struct drm_fb_helper *helper, goto err_fb_info_destroy; } - fb = &fbdev_cma->fb->fb; + fb = fbdev_cma->fb; helper->fb = fb; fbi->par = helper; @@ -500,7 +474,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper, return 0; err_cma_destroy: - drm_framebuffer_remove(&fbdev_cma->fb->fb); + drm_framebuffer_remove(fbdev_cma->fb); err_fb_info_destroy: drm_fb_helper_fini(helper); err_gem_free_object: @@ -598,7 +572,7 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma) drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev); if (fbde...

...rm_fbdev_cma_create(struct drm_fb_helper *helper, goto err_fb_info_destroy; } - fb = &fbdev_cma->fb->fb; + fb = fbdev_cma->fb; helper->fb = fb; fbi->par = helper; @@ -500,7 +474,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper, return 0; err_cma_destroy: - drm_framebuffer_remove(&fbdev_cma->fb->fb); + drm_framebuffer_remove(fbdev_cma->fb); err_fb_info_destroy: drm_fb_helper_fini(helper); err_gem_free_object: @@ -598,7 +572,7 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma) drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev); if (fbde...

...l > gracefully although the latter seems to leak the object from > bochsfb_create_object (not a regression). > > Guess on the reason for the encoder leak: drm_framebuffer_cleanup was > previously used, but did not destroy much. drm_fb_helper_fbdev_teardown > is now used and calls drm_framebuffer_remove which does a bit more work. > > Tested with 'echo 0 > /sys/class/vtconsole/vtcon1/bind; rmmod bochs_drm' > and also with Xorg + fbdev (startx -> xterm). The latter triggered a > warning in ttm_bo_vm_open that existed before, see > https://lkml.kernel.org/r/1464000533-...

...1 nyx kernel: nv50_base_update+0x2a/0xf0 [nouveau] Dec 30 12:17:21 nyx kernel: nv50_disp_atomic_commit_tail+0x64a/0x3980 [nouveau] Dec 30 12:17:21 nyx kernel: nv50_disp_atomic_commit+0x26e/0x280 [nouveau] Dec 30 12:17:21 nyx kernel: drm_atomic_commit+0x4b/0x50 [drm] Dec 30 12:17:21 nyx kernel: drm_framebuffer_remove+0x2a5/0x3c0 [drm] Dec 30 12:17:21 nyx kernel: drm_mode_rmfb_work_fn+0x55/0x70 [drm] Dec 30 12:17:21 nyx kernel: process_one_work+0x193/0x3c0 Dec 30 12:17:21 nyx kernel: worker_thread+0x35/0x3b0 Dec 30 12:17:21 nyx kernel: kthread+0x125/0x140 Dec 30 12:17:21 nyx kernel: ? process_one_work+0x3c...