On Wed, Dec 5, 2012 at 12:55 AM, Inki Dae inki.dae@samsung.com wrote:
Hi
2012/12/5 Prathyush K prathyush@chromium.org
Hi,
Please check the reference counts for framebuffers: This is for one modetest (without flipping)
Bootup: [ 2.310000] KP: drm_framebuffer_init edb86900 - fb0 refcount 1 [ 2.310000] KP: drm_framebuffer_reference edb86900 - fb0 refcount 2
Modetest: [ 26.560000] KP: drm_framebuffer_init ed43c900 - fb1 refcount 1 (done in addFB) [ 26.560000] KP: drm_framebuffer_reference ed43c900 - fb1 refcount 2 (done in setCRTC for new fb) [ 26.570000] KP: drm_framebuffer_unreference edb86900 - fb0 refcount 1 (done in setCRTC for old fb)
End of modetest and drm release: [ 39.080000] KP: drm_framebuffer_unreference ed43c900 - fb1 refcount 1 (this is done by the unref in drm_framebuffer_remove) [ 39.100000] KP: drm_framebuffer_reference edb86900 - fb0 refcount 2 (this is done when we restore fbdev)
At the end of modetest, you can see that fb1 refcount is still 1 and the memory does not get freed.
You can put a print in the low level buffer allocate and deallocate and you can see that deallocate does not get called for fb1.
And also, I see a new dma-address getting created each time - e.g. 20400000, 20800000, 20C00000.
Please check modetest without enabling flipping. modetest -s 17@4:1280x720.
We missed the test without vblank. Right tested and confirmed.
just fwiw, I've found debugfs file giving a dump of all the fb's and gem objects in omapdrm has been quite useful in testing for and debugging memory leaks
BR, -R