Comment # 8
on bug 104439
from Urs Fleisch
I have verified if the git bisect has found the real bad commit and can confirm
that
c7c6e46f913b drm/i915: Convert execbuf to use struct-of-array packing for
critical fields
is the last good commit. Two commits later
commit 170fa29b14fadf2deb361589cefe6a78b21b1b22
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Aug 16 09:52:07 2017 +0100
drm/i915: Simplify eb_lookup_vmas()
Since the introduction of being able to perform a lockless lookup of an
object (i915_gem_object_get_rcu() in fbbd37b36fa5 ("drm/i915: Move object
release to a freelist + worker") we no longer need to split the
object/vma lookup into 3 phases and so combine them into a much simpler
single loop.
and
commit d1b48c1e7184d9bc4ae6d7f9fe2eed9efed11ffc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Aug 16 09:52:08 2017 +0100
drm/i915: Replace execbuf vma ht with an idr
This was the competing idea long ago, but it was only with the rewrite
of the idr as an radixtree and using the radixtree directly ourselves,
along with the realisation that we can store the vma directly in the
radixtree and only need a list for the reverse mapping, that made the
patch performant enough to displace using a hashtable. Though the vma ht
is fast and doesn't require any extra allocation (as we can embed the node
inside the vma), it does require a thread for resizing and serialization
and will have the occasional slow lookup. That is hairy enough to
investigate alternatives and favour them if equivalent in peak performance.
One advantage of allocating an indirection entry is that we can support a
single shared bo between many clients, something that was done on a
first-come first-serve basis for shared GGTT vma previously. To offset
the extra allocations, we create yet another kmem_cache for them.
the bug was introduced. Graphics are distorted, the Linux kernel is not really
usable with my Intel graphics Q35.
The bug is easy to reproduce: Start the Chromium and browse maps.google.com.
Chromium reports
intel_do_flush_locked failed: Invalid argument
Using strace on ioctl, I can see that the invalid argument is caused by
ioctl(129, DRM_IOCTL_I915_GEM_EXECBUFFER2_WR, 0x7ffd8b5b6540) = -1 EINVAL
(Invalid argument)
Using some printk debugging, it can be seen that i915_gem_execbuffer2() returns
first -512=-ERESTARTSYS and then four times -22=-EINVAL.
@Chris Wilson: Could you please have a look at the problem? Do you have old
Intel graphics Q35 available to reproduce the issue? I would fix the problem
myself if I had enough knowledge about this driver. The best I could probably
do would be to introduce a module parameter to restore the old behavior using
the hashtable instead of the radix tree, but there must be a better solution to
use the new radix tree and keep it working on old Intel graphics hardware. I
will provide you with as much information as needed and will check patches once
you have some available.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
