[Bug 78237] New: [ILK bisected]igt/gem_pin fails
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Sat May 3 19:24:21 PDT 2014
https://bugs.freedesktop.org/show_bug.cgi?id=78237
Priority: medium
Bug ID: 78237
CC: intel-gfx-bugs at lists.freedesktop.org
Assignee: intel-gfx-bugs at lists.freedesktop.org
Summary: [ILK bisected]igt/gem_pin fails
QA Contact: intel-gfx-bugs at lists.freedesktop.org
Severity: normal
Classification: Unclassified
OS: All
Reporter: jinxianx.guo at intel.com
Hardware: Other
Status: NEW
Version: unspecified
Component: DRM/Intel
Product: DRI
Created attachment 98393
--> https://bugs.freedesktop.org/attachment.cgi?id=98393&action=edit
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 at chris-wilson.co.uk>
AuthorDate: Mon Mar 17 12:21:55 2014 +0000
Commit: Daniel Vetter <daniel.vetter at 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 at chris-wilson.co.uk>
Tested-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin at intel.com>
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/20140504/4ee20172/attachment-0001.html>
More information about the intel-gfx-bugs
mailing list