Bug 79005

Summary: [all bisected]igt/gem_mmap/new-object fails
Product: DRI Reporter: Guo Jinxian <jinxianx.guo>
Component: DRM/IntelAssignee: Chris Wilson <chris>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: blocker    
Priority: highest CC: intel-gfx-bugs
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg
none
Only discard backing storage on last ref
none
dmesg none

Description Guo Jinxian 2014-05-21 08:44:26 UTC
Created attachment 99476 [details]
dmesg

==System Environment==
--------------------------
Regression: Yes. 

Non-working platforms: ILK SNB IVB HSW

==kernel==
--------------------------
-nightly: 36765340cb068dec1216342bfcdbf2678ec29860(fails)
-queued: bc76e320f21f8bd790a72bd5dc06909617432352(fails)
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue May 20 22:46:50 2014 +0200

    drm/i915: Drop now misleading DDI comment from dp_link_down

    Since

    commit 2e82a7203182d0883d0f9450d40ad6e1c6578ad9
    Author: Imre Deak <imre.deak@intel.com>
    Date:   Fri Jan 17 15:46:43 2014 +0200

        drm/i915: don't disable DP port after a failed link training

    and

    commit 5d6a1116c6475404e6505b708320f9579ae19acd
    Author: Imre Deak <imre.deak@intel.com>
    Date:   Thu Jan 16 18:35:57 2014 +0200

        drm/i915: don't disable the DP port if the link is lost

    we no longer call intel_dp_link_down from generic DP code, but only
    from the !HAS_DDI dp encoder functions. hsw/bdw have their own encoder
    disabling callback in intel_ddi.c.

    Hence the early return is no longer needed and the big comment just
    confusing, so let's rip it out. To ensure what we don't accidentally
    use this again on ddi encoders add a WARN_ON instead.

    Spotted while reading through intel_dp.c

    Cc: Imre Deak <imre.deak@intel.com>
    Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    
-fixes: 4ba4801d73d14690ed15774424e8b1d4c18323a5(works)
    Author: Dave Airlie <airlied@redhat.com>
Date:   Tue May 20 09:56:26 2014 +1000

    Merge tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel into drm-fixes

    Intel fixes for regressions, black screens and hangs, for 3.15.

    * tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel:
      drm/i915: Increase WM memory latency values on SNB
      drm/i915: restore backlight precision when converting from ACPI
      drm/i915: Use the first mode if there is no preferred mode in the EDID
      drm/i915/dp: force eDP lane count to max available lanes on BDW
      drm/i915/vlv: reset VLV media force wake request register
      drm/i915/SDVO: For sysfs link put directory and target in correct order
      drm/i915: use lane count and link rate from VBT as minimums for eDP
      drm/i915: clean up VBT eDP link param decoding
      drm/i915: consider the source max DP lane count too

==Bug detailed description==
-----------------------------
igt/gem_mmap/new-object fails

Output:
./gem_mmap --run-subtest new-object
IGT-Version: 1.6-g737d248 (x86_64) (Linux: 3.15.0-rc5_drm-intel-nightly_367653_20140521+ x86_64)
Testing contents of newly created object.
Testing coherency of writes and mmap reads.
Testing that mapping stays after close
Test assertion failure function __real_main45, file gem_mmap.c:89:
Last errno: 0, Success
Failed assertion: memcmp(buf, addr, sizeof(buf)) == 0
Subtest new-object: FAIL

==Reproduce steps==
---------------------------- 
1. ./gem_mmap --run-subtest new-object

==Bisect results==
----------------------------
Bisect shows: 5537252b6b6d71fb1a8ed7395a8e5babf91953fd is the first bad commit
commit 5537252b6b6d71fb1a8ed7395a8e5babf91953fd
Author:     Chris Wilson <chris@chris-wilson.co.uk>
AuthorDate: Tue Mar 25 13:23:06 2014 +0000
Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Tue May 20 09:51:18 2014 +0200

    drm/i915: Invalidate our pages under memory pressure

    Try to flush out dirty pages into the swapcache (and from there into the
    swapfile) when under memory pressure and forced to drop GEM objects from
    memory. In effect, this should just allow us to discard unused pages for
    memory reclaim and to start writeback earlier.

    v2: Hugh Dickins warned that explicitly starting writeback from
    shrink_slab was prone to deadlocks within shmemfs.

    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Robert Beckett <robert.beckett@intel.com>
    Reviewed-by: Rafael Barbalho <rafael.barbalho@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 1 Chris Wilson 2014-05-21 08:49:10 UTC
Grr. I liked that implicit release upon close.
Comment 2 lu hua 2014-05-21 08:52:47 UTC
It fails on all platforms.
Comment 3 Chris Wilson 2014-05-21 09:26:06 UTC
Created attachment 99488 [details] [review]
Only discard backing storage on last ref
Comment 4 Daniel Vetter 2014-05-22 06:38:05 UTC
Ramping up priority for testing, I'd like to get this patch merged asap.
Comment 5 Guo Jinxian 2014-05-22 08:13:11 UTC
Created attachment 99566 [details]
dmesg

(In reply to comment #3)
> Created attachment 99488 [details] [review] [review]
> Only discard backing storage on last ref
Test was passed with the patch.
./gem_mmap --run-subtest new-object
IGT-Version: 1.6-gc75dcbd (x86_64) (Linux: 3.14.0_kcloud_b0631c_20140522+ x86_64)
Testing contents of newly created object.
Testing coherency of writes and mmap reads.
Testing that mapping stays after close
Testing unmapping
Subtest new-object: SUCCESS
Comment 6 Daniel Vetter 2014-05-22 08:26:50 UTC
commit 83efdab1279246b2238a2d926b6b34450cc15be1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu May 22 09:16:52 2014 +0100

    drm/i915: Only discard backing storage on releasing the last ref
Comment 7 Guo Jinxian 2014-05-23 05:25:37 UTC
Verified.
Comment 8 Jari Tahvanainen 2016-10-12 10:37:27 UTC
Closing verified+fixed.

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.