[Bug 93251] New: i915 is leaking frame buffers

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93251

            Bug ID: 93251
           Summary: i915 is leaking frame buffers
           Product: DRI
           Version: unspecified
          Hardware: Other
                OS: All
            Status: NEW
          Severity: major
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: tvrtko.ursulin at linux.intel.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

(Since appealing to people directly does not seem to work, here is an Bugzilla
entry so I've done my bit.)

Definitely when legacy fbcon is not enabled, maybe even leaks extra
(non-primary) planes with it.

I ran igt/kms_rotation_crc on a system without legacy fbcon and it crashed.
This left any planes it happened to be displaying stuck on screen.

For example kms_rotation_crc has crashed, and kernel still hangs onto the frame
buffers:

# cat /sys/kernel/debug/dri/0/i915_gem_framebuffer 
user size: 128 x 128, depth 32, 32 bpp, modifier 0x0, refcount 2, obj
ffff8800aa0486c0:  p g       64KiB 40 00 [ 0 0 0 0 ] 0 0 uncached dirty (pinned
x 1) (display) (ggtt offset: 0281b000, size: 00010000, type: 0) (pf mappable)
(frontbuffer: 0x002)
user size: 1920 x 1080, depth 24, 32 bpp, modifier 0x0, refcount 2, obj
ffff8800aa049d40:  p g     8100KiB 41 00 [ 0 0 0 0 ] 0 0 uncached (pinned x 1)
(display) (ggtt offset: 0282b000, size: 007e9000, type: 0) (p mappable)
(frontbuffer: 0x001)
user size: 1920 x 1080, depth 24, 32 bpp, modifier 0x0, refcount 2, obj
ffff8800aa048fc0:  p g     8100KiB 40 00 [ 0 0 0 0 ] 0 0 uncached dirty (pinned
x 1) (display) (ggtt offset: 00819000, size: 007e9000, type: 0) (pf mappable)
(frontbuffer: 0x004)

One consequence is that should the user start something which puts stuff on the
primary plane, say igt/testdisplay, the sprite and cursor belonging to gone
kms_rotation_crc will still be on screen. Even hiding the testdisplay output.

And it also makes subsequent CRC tests fail.

When I now start Xorg the desktop is hidden by the left over sprite plane.

Imagine a scenario with multiple displays and multiple planes and Xorg
segfaults. Kernel will keep, number of displays times number of planes frame
buffers around, pinned in memory, wasting resources.

Not to mention it keeps displaying potentially sensitive data on screen.

Someone will say it is an userspace problem, that something should enumerate
all displays and all planes and clear them should a display server crash.  I
disagree because that would mean changing all existing userspace programs which
currently assume that when they start up nothing is on screen or on the extra
planes.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20151204/d33b491b/attachment.html>