Created attachment 106171 [details] output of cat /sys/kernel/debug/kmemleak I noticed this when debugging suspend/resume problem with ubuntu 14.04 + 3.17rc4 (or latest next) kernel compiled. The suspend/resume problem i have is not i915 related. steps to reproduce: 1. compile kernel with CONFIG_DEBUG_KMEMLEAK and CONFIG_PM_DEBUG 2. Run: echo clear > /sys/kernel/debug/kmemleak 3. Run: echo core > /sys/power/pm_test 4. Run: echo mem > /sys/power/state 5. Run: echo scan > /sys/kernel/debug/kmemleak 6. Run: cat /sys/kernel/debug/kmemleak 7. check output. a lot of entries like this occurs: unreferenced object 0xffff880405960980 (size 32): comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s) hex dump (first 32 bytes): d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00 ..F............. 98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00 .`(............. backtrace: [<ffffffff81816f9e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811fa678>] kmem_cache_alloc_trace+0x168/0x2f0 [<ffffffffc03e20a5>] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915] [<ffffffffc04088a2>] intel_init_ring_buffer+0x202/0x470 [i915] [<ffffffffc040c998>] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915] [<ffffffffc03eff59>] i915_gem_init_hw+0x2f9/0x3a0 [i915] [<ffffffffc03f0057>] i915_gem_init+0x57/0x1d0 [i915] [<ffffffffc045e26a>] i915_driver_load+0xc0a/0x10e0 [i915] [<ffffffffc02e0d5d>] drm_dev_register+0xad/0x100 [drm] [<ffffffffc02e3b9f>] drm_get_pci_dev+0x8f/0x200 [drm] [<ffffffffc03c934b>] i915_pci_probe+0x3b/0x60 [i915] [<ffffffff81436725>] local_pci_probe+0x45/0xa0 [<ffffffff81437a69>] pci_device_probe+0xd9/0x130 [<ffffffff81524f4d>] driver_probe_device+0x12d/0x3e0 [<ffffffff815252d3>] __driver_attach+0x93/0xa0 [<ffffffff81522e1b>] bus_for_each_dev+0x6b/0xb0 usually the allocating function is i915_cmd_parser_init_ring but the rest of the stack might be different. Im not familiar with this driver at all but I think ring buffer should be deleted/cleaned from suspend but now it is only stopping ring buffer? This leak seems to be cumulative so every resume allocates that again but suspend does not release it.
The problem is that the rings are initialised multiple times. See http://patchwork.freedesktop.org/patch/33175/
Ok it was known issue then. When that is released to upstream kernel? or is that part of drm intel nightly? I'm about to test drm intel nightly to see if it fixes the refresh rate problem I have with asus pb287q + DP1.2.
Chris' patches are still in review, not part of nightly. I doubt they'll make it upstream (as in Linus' tree) before 3.19. Chris, is it possible/feasible to have a separate fix for the memleak? Kari, please just file new bugs for other issues, such as refresh rate, you may have. Thanks.
Created attachment 106565 [details] [review] drm/i915: Don't leak command parser tables on suspend/resume
Kari, can you please test with https://bugs.freedesktop.org/attachment.cgi?id=106565 ? It should address the leak without having to wait for the full ring initialization fix.
Brad, I tested your patch on top of linux-next-20140919 and I don't see those leaks anymore. Without your patch, I saw the leaks with linux-next-20140919. Jani, I'll file a bug from the refresh rate problem after I have little bit more time to check it and figure out the component where to file a bug. I asked it from https://01.org/linuxgraphics/node/388 but did not get any answer.
commit 22cb99af39b5d4aae075a5bc9da615ba245227cd Author: Brad Volkin <bradley.d.volkin@intel.com> Date: Mon Sep 22 08:25:21 2014 -0700 drm/i915: Don't leak command parser tables on suspend/resume
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.