<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - ZaphodHeads + TearFree cause what looks like severe double buffering synchronization problems"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104343#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - ZaphodHeads + TearFree cause what looks like severe double buffering synchronization problems"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104343">bug 104343</a>
from <span class="vcard"><a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> <span class="fn">Chris Wilson</span></a>
</span></b>
<pre>(In reply to Werner Almesberger from <a href="show_bug.cgi?id=104343#c2">comment #2</a>)
<span class="quote">> I compiled the driver from git, with
>
> ./autogen.sh --enable-debug=full --prefix=/usr
> make
> make install
>
> The X server picks it up, but fails initialization with
>
> to_sna:499 assertion 'sna->scrn == scrn' failed
>
> Full log:
> <a href="https://almesberger.net/paste/Xorg.0.log-Fae9oiPh.txt">https://almesberger.net/paste/Xorg.0.log-Fae9oiPh.txt</a></span >
commit 032a581fd7037c9d2e5fdc91d325db6a7e133b7f (HEAD, upstream/master)
Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
Date: Wed Dec 20 08:25:25 2017 +0000
sna: Fixup sna->scrn == scrn assert for early initialisation
Very early on when creating the sna privates, we call to_sna(scrn) before
we have even set the sna->scrn backpointer. Reorder the code such that
we always set sna->scrn before the first to_sna() so that the
assert(to_sna(scrn)->scrn == scrn) can always hold.
Signed-off-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
<span class="quote">> Sadly, when trying to return to the configuration that worked before, I now
> still get the problems I had initially. So this means that, either
> 1) that appearance of the problem is affected by other variables (and may
> not have anything to do with TearFree)
> 2) make uninstall (of xserver-xorg-video-intel) left something behind,
> 3) apt-get removing and then re-installing the xserver-xorg-video-intel
> package caused some change
> 3) I introduced a change when editing xorg.conf back and forth for testing
> the driver compiled from git
>
> Regarding 3), I checked in the log that TearFree is always disable.
> Regarding 1), I tried to repeat the sequence of configurations that led to
> the successful run, in particular the configuration that disabled TearFree
> only in one case, followed by the correct one, but that didn't help.</span >
Refresh the log file for the now always failing case, maybe something stands
out. If the damage tracking is broken, then anything that triggers the damage
tracking (essentially CPU access to the frontbuffer, which uses a shadow
buffer) will result in glitches. TearFree requires damage tracking to keep a
back buffer uptodate, so should always run into trouble if that is wrong.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>