Bug 78237

Summary: [ILK bisected]igt/gem_pin 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: normal    
Priority: high CC: intel-gfx-bugs
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg none

Description Guo Jinxian 2014-05-04 02:24:21 UTC
Created attachment 98393 [details]
dmesg

*System Environment:
--------------------------
Platform: ILK
kernel: 
-nightly: 08ce6614d07dd1e426109672a5e323317c8d6ec7(fails)
-queued: e5c03ca362819ba8ffbe5674340b61b9cd75de8f (fails)
-fixes: 9bbfd20abe5025adbb0ac75160bd2e41158a9e83 (works)


 *Bug detailed description:
-----------------------------
igt/gem_pin fails. 

It's a regression issue


Output:
./gem_pin
IGT-Version: 1.6-gc864279 (x86_64) (Linux: 3.15.0-rc2_drm-intel-nightly_08ce66_20140503+ x86_64)
Test assertion failure function gem_pin, file gem_pin.c:200:
Last errno: 28, No space left on device
Failed assertion: drmIoctl((fd), ((((2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0x40 + 0x15)) << 0) | ((((sizeof(struct drm_i915_gem_pin)))) << ((0+8)+8)))), (&pin)) == 0

 *Reproduce steps:
---------------------------- 
1. ./gem_pin

*Bisect results:
----------------------------
9403eb1064168ea7b47c5ccd04ec17b98ca9a0de is the first bad commit
commit 9403eb1064168ea7b47c5ccd04ec17b98ca9a0de
Author:     Chris Wilson <chris@chris-wilson.co.uk>
AuthorDate: Mon Mar 17 12:21:55 2014 +0000
Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Fri Apr 25 16:18:01 2014 +0200

    drm/i915: Do not call retire_requests from wait_for_rendering

    A common issue we have is that retiring requests causes recursion
    through GTT manipulation or page table manipulation which we can only
    handle at very specific points. However, to maintain internal
    consistency (enforced through our sanity checks on write_domain at
    various points in the GEM object lifecycle) we do need to retire the
    object prior to marking it with a new write_domain, and also clear the
    write_domain for the implicit flush following a batch.

    Note that this then allows the unbound objects to still be on the active
    lists, and so care must be taken when removing objects from unbound lists
    (similar to the caveats we face processing the bound lists).

    v2: Fix i915_gem_shrink_all() to handle updated object lifetime rules,
    by refactoring it to call into __i915_gem_shrink().

    v3: Missed an object-retire prior to changing cache domains in
    i915_gem_object_set_cache_leve()

    v4: Rebase

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment 1 Chris Wilson 2014-05-08 12:34:36 UTC
It doesn't make any sense, as before ENOSPC is returned, i915_gem_evict_something() does a pass after explicitly retiring requests. gem_pin runs fine on my ilk device. So presuming fixed.
Comment 2 Guo Jinxian 2014-05-15 05:37:23 UTC
Checkout on latest -nightly(c74cad3c2599b47438b168ca5629fbb00ab63f95), This bug had fixed. Thanks.
Comment 3 Jari Tahvanainen 2017-07-03 13:55:27 UTC
Closing old 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.