On Wed, Dec 5, 2012 at 12:55 AM, Inki Dae <inki.dae@xxxxxxxxxxx> wrote: > Hi > > 2012/12/5 Prathyush K <prathyush@xxxxxxxxxxxx> >> >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
