<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - GPU Hangs since Kernel-4.2 upgrade"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91894#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - GPU Hangs since Kernel-4.2 upgrade"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91894">bug 91894</a>
from <span class="vcard"><a class="email" href="mailto:krejzi@email.com" title="Armin K <krejzi@email.com>"> <span class="fn">Armin K</span></a>
</span></b>
<pre>Now, this is confusing. git bisect says the following:
0875546c5318c85c13d07014af5350e9000bc9e9 is the first bad commit
commit 0875546c5318c85c13d07014af5350e9000bc9e9
Author: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>>
Date: Mon Apr 20 09:04:05 2015 -0700
drm/i915: Fix up the vma aliasing ppgtt binding
Currently we have the problem that the decision whether ptes need to
be (re)written is splattered all over the codebase. Move all that into
i915_vma_bind. This needs a few changes:
- Just reuse the PIN_* flags for i915_vma_bind and do the conversion
to vma->bound in there to avoid duplicating the conversion code all
over.
- We need to make binding for EXECBUF (i.e. pick aliasing ppgtt if
around) explicit, add PIN_USER for that.
- Two callers want to update ptes, give them a PIN_UPDATE for that.
Of course we still want to avoid double-binding, but that should be
taken care of:
- A ppgtt vma will only ever see PIN_USER, so no issue with
double-binding.
- A ggtt vma with aliasing ppgtt needs both types of binding, and we
track that properly now.
- A ggtt vma without aliasing ppgtt could be bound twice. In the
lower-level ->bind_vma functions hence unconditionally set
GLOBAL_BIND when writing the ggtt ptes.
There's still a bit room for cleanup, but that's for follow-up
patches.
v2: Fixup fumbles.
v3: s/PIN_EXECBUF/PIN_USER/ for clearer meaning, suggested by Chris.
Cc: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Reviewed-by: Mika Kuoppala <<a href="mailto:mika.kuoppala@intel.com">mika.kuoppala@intel.com</a>>
Signed-off-by: Daniel Vetter <<a href="mailto:daniel.vetter@intel.com">daniel.vetter@intel.com</a>>
However, checking out that revision and building it, all is fine. Now, the two
commits after that revision introduced the problem.
First one, fa42331b4cd961cecb3f6919116d2e6efeb2334b didn't introduce a real
problem, but a hang happened when I closed the video tab where the video was
playing, not while playing.
Second one, 4755265977159be0261972da2ba54917765b18ed introduced the real
problem, ie hangs all over the place when a video was playing and gst-vaapi was
utilized.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>