[Bug 86679] [ILK i386 Bisected]X start fail

[bugzilla-daemon at freedesktop.org]

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

lu hua <huax.lu at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|bisect_pending              |
             Status|NEEDINFO                    |NEW
           Assignee|intel-gfx-bugs at lists.freede |daniel at ffwll.ch
                   |sktop.org                   |
            Summary|[ILK i386 regression]X      |[ILK i386 Bisected]X start
                   |start fail                  |fail

--- Comment #7 from lu hua <huax.lu at intel.com> ---
Bisect shows 83f45fc360c8e16a330474860ebda872d1384c8c is the first bad commit.
revert it, this issue goes away.
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author:     Daniel Vetter <daniel.vetter at ffwll.ch>
AuthorDate: Wed Aug 6 09:10:18 2014 +0200
Commit:     Daniel Vetter <daniel.vetter at ffwll.ch>
CommitDate: Wed Aug 6 10:41:13 2014 +0200

    drm: Don't grab an fb reference for the idr

    The current refcounting scheme is that the fb lookup idr also holds a
    reference. This works out nicely bacause thus far we've always
    explicitly cleaned up idr entries for framebuffers:
    - Userspace fbs get removed in the rmfb ioctl or when the drm file
      gets closed.
    - Kernel fbs (for fbdev emulation) get cleaned up by the driver code
      at module unload time.

    But now i915 also reconstructs the bios fbs for a smooth transition.
    And that fb is purely transitional and should get removed immmediately
    once all crtcs stop using it. Of course if the i915 fbdev code decides
    to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
    in that case the fbdev code will grab it's own reference.

    The problem is now that we also want to register that takeover fb in
    the idr, so that userspace can do a smooth transition (animated maybe
    even!) itself. But currently we have no one who will clean up the idr
    reference once that fb isn't useful any more, and so essentially leak
    it.

    Fix this by no longer holding a full fb reference for the idr, but
    instead just have a weak reference using kref_get_unless_zero. But
    that requires us to synchronize and clean up with the idr and fb_lock
    in drm_framebuffer_free, so add that. It's a bit ugly that we have to
    unconditionally grab the fb_lock, but without that someone might creep
    through a race.

    This leak was caught by the fb leak check in drm_mode_config_cleanup.
    Originally the leak was introduced in

    commit 46f297fb83d4f9a6f6891964beb184664341a28b
    Author: Jesse Barnes <jbarnes at virtuousgeek.org>
    Date:   Fri Mar 7 08:57:48 2014 -0800

        drm/i915: add plane_config fetching infrastructure v2

    Cc:  Jesse Barnes <jbarnes at virtuousgeek.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>

-- 
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/20141126/16621139/attachment.html>