Bug 87279 - Intel GM45 graphics glitches with Kernel 3.18.0
Summary: Intel GM45 graphics glitches with Kernel 3.18.0
Status: CLOSED DUPLICATE of bug 86679
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-13 10:59 UTC by Ugis
Modified: 2017-07-24 22:49 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Glitch (255.07 KB, text/plain)
2014-12-13 10:59 UTC, Ugis
no flags Details
dmesg drm debug (99.87 KB, text/plain)
2014-12-13 13:45 UTC, Ugis
no flags Details
Xorg log (22.06 KB, text/plain)
2014-12-13 13:46 UTC, Ugis
no flags Details
Glx info (11.41 KB, text/plain)
2014-12-13 13:46 UTC, Ugis
no flags Details
drm-i915-Disallow-pin-ioctl-completely-for-kms-drive.patch (2.66 KB, patch)
2014-12-15 09:52 UTC, Ugis
no flags Details | Splinter Review

Description Ugis 2014-12-13 10:59:25 UTC
Created attachment 110810 [details]
Glitch

Kernel 3.18 causes graphics glitches in kde

Here's a video: http://youtu.be/zPvukTJH6Ec

Noting interesting in my dmesg or journalctl but someone who has the same problem posted this: https://dl.dropboxusercontent.com/u/2135959/dmesgbroken

Interesting that this doesn't happen on drm-intel-nightly kernel. (So it's fixed somewhere?)
Comment 1 Ugis 2014-12-13 13:44:28 UTC
Additional Info:
-- chipset: gm45
-- system architecture: x86_64
-- xf86-video-intel version: 2.99.916-1
-- xserver version: 1.16.2-1 
-- mesa version: 10.3.5
-- libdrm version: 2.4.58-1
-- kernel: linux 3.18
-- Linux distribution: Chakra
-- Machine: Dell Vostro 1015

xorg log and dmesg drm debug: will attach
Comment 2 Ugis 2014-12-13 13:45:32 UTC
Created attachment 110815 [details]
dmesg drm debug
Comment 3 Ugis 2014-12-13 13:46:10 UTC
Created attachment 110816 [details]
Xorg log
Comment 4 Ugis 2014-12-13 13:46:53 UTC
Created attachment 110817 [details]
Glx info
Comment 5 Ugis 2014-12-14 13:37:03 UTC
The problem exists in drm-intel-fixes branch (2014.09.05.r13494.gb0616c5)
But is fixed in drm-intel-nightly branch. (2014.12.05.r310.gbfdd01a)
Does anyone know which commit/patch would be responsible?
Comment 6 Ben Widawsky 2014-12-14 18:53:19 UTC
You've provided enough information to bisect this. If you have the time, please do that.
Comment 7 Ugis 2014-12-15 04:54:58 UTC
After long night of bisecting, I've found the commit that seem to fix this bug
---------------------------------------------------------------------------
d472fcc8379c062bd56a3876fc6ef22258f14a91 is the first bad commit
commit d472fcc8379c062bd56a3876fc6ef22258f14a91
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Nov 24 11:12:42 2014 +0100

    drm/i915: Disallow pin ioctl completely for kms drivers
    
    The problem here is that SNA pins batchbuffers to etch out a bit more
    performance. Iirc it started out as a w/a for i830M (which we've
    implemented in the kernel since a long time already). The problem is
    that the pin ioctl wasn't added in
    
    commit d23db88c3ab233daed18709e3a24d6c95344117f
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Fri May 23 08:48:08 2014 +0200
    
        drm/i915: Prevent negative relocation deltas from wrapping
    
    Fix this by simply disallowing pinning from userspace so that the
    kernel is in full control of batch placement again. Especially since
    distros are moving towards running X as non-root, so most users won't
    even be able to see any benefits.
    
    UMS support is dead now, but we need this minimal patch for
    backporting. Follow-up patch will remove the pin ioctl code
    completely.
    
    Note to backporters: You must have both
    
    commit b45305fce5bb1abec263fcff9d81ebecd6306ede
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Mon Dec 17 16:21:27 2012 +0100
    
        drm/i915: Implement workaround for broken CS tlb on i830/845
    
    which laned in 3.8 and
    
    commit c4d69da167fa967749aeb70bc0e94a457e5d00c1
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Mon Sep 8 14:25:41 2014 +0100
    
        drm/i915: Evict CS TLBs between batches
    
    which is also marked cc: stable. Otherwise this could introduce a
    regression by disabling the userspace w/a without the kernel w/a being
    fully functional on i830/45.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116
    Cc: stable@vger.kernel.org # requires c4d69da167fa967749a and v3.8
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

:040000 040000 4345ff9fc3b775222a59890caf35c033b5a5bacf c8a157f364e4e0490b6bf1df0321a24bfd069f2e M      drivers
Comment 8 Ugis 2014-12-15 09:52:19 UTC
Created attachment 110848 [details] [review]
drm-i915-Disallow-pin-ioctl-completely-for-kms-drive.patch
Comment 9 Ugis 2014-12-15 10:35:11 UTC
Comment on attachment 110848 [details] [review]
drm-i915-Disallow-pin-ioctl-completely-for-kms-drive.patch

Tested on Chakra's 3.18.0 Kernel. Seems to fix the problem, no adverse effects noticed so far.
Comment 10 Ugis 2014-12-17 15:06:18 UTC
I bisected the changes between 3.17 and 3.18 to find out which commit introduces the bug:
This is the result:
-------------------------------------------------------------
83f45fc360c8e16a330474860ebda872d1384c8c is the first bad commit
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 6 09:10:18 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@virtuousgeek.org>
    Date:   Fri Mar 7 08:57:48 2014 -0800
    
        drm/i915: add plane_config fetching infrastructure v2
    
    Cc:  Jesse Barnes <jbarnes@virtuousgeek.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 5531f93c825c20036d2090260ca376d4f4586e54 00ffd9236297fafb105ea470db008d991377241f M      drivers
-----------------------------------------------------------------------------
Cgit url: http://cgit.freedesktop.org/drm-intel/commit/?id=83f45fc360c8e16a330474860ebda872d1384c8c
-----------------------------------------------------------------------------
Reverting the commit fixes the issue.
Comment 11 Jani Nikula 2014-12-17 15:25:10 UTC

*** This bug has been marked as a duplicate of bug 86679 ***
Comment 12 Ugis 2014-12-21 12:35:41 UTC
I'm sorry but the attached drm-i915-Disallow-pin-ioctl-completely-for-kms-drive.patch  seems to be mangled somehow and doesn't build on some systems
Please use the patch directly from cgit:

http://cgit.freedesktop.org/drm-intel/patch/?id=d472fcc8379c062bd56a3876fc6ef22258f14a91


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.