<br><br><div class="gmail_quote">On Sun, Jan 29, 2012 at 7:34 PM, Matt Garman <span dir="ltr">&lt;<a href="mailto:matthew.garman@gmail.com">matthew.garman@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Jan 28, 2012 at 01:55:31PM -0600, william otten wrote:<br>
&gt; The patch is quite simple and involves one function in<br>
&gt; mesa/drivers/dri/intel/intel_screen.c<br>
</div><div class="im">&gt; Another person on this list<br>
&gt; reported that the patch solved an identical crash for him.  Before<br>
&gt; diving into much debugging, I suggest you apply this patch to the mesa<br>
&gt; 7.11.2 code, recompile it, and give it a test.<br>
<br>
</div>I may be the &quot;other person&quot; who has been referred to several times<br>
in this thread, as I did exactly that: I patched the intel_screen.c<br>
file and rebuilt mesa, and now have a nicely working OpenGL-based<br>
SNB frontend (which I&#39;m proud to say is also quite small and<br>
low-power :).<br>
<br>
&gt;From my skimming of this thread, it looks like the individual with<br>
the patching issues is running Ubuntu.  I&#39;m running CentOS plus<br>
ATrpms (for MythTV) and elrepo for newer Intel video drivers and<br>
supporting packages (in particular, mesa).<br>
<br>
What I did was simply download the source RPM for mesa from elrepo,<br>
manually hack the intel_screen.c file according to the patch, and<br>
rebuild.  I don&#39;t know how to do this with Ubuntu/debian packages,<br>
but I can&#39;t imagine the process is dramatically different from an<br>
RPM-based distro.<br>
<br>
FWIW, the patch that has been mentioned doesn&#39;t apply cleanly to the<br>
mesa source from elrepo, because it&#39;s a slightly older version:<br>
looks like the mesa-20111103 snapshot.<br>
<br>
But the patch is super simple.  Just look for the function<br>
&quot;intelDRI2Flush()&quot; in the file mentioned above.  It should be near<br>
the top of the file.  Just replace that function definition with<br>
this one:<br>
<br>
static void<br>
intelDRI2Flush(__DRIdrawable *drawable)<br>
{<br>
   GET_CURRENT_CONTEXT(ctx);<br>
   struct intel_context *intel = intel_context(ctx);<br>
<br>
   if (intel != NULL) { /* add this... */<br>
       if (intel-&gt;gen &lt; 4)<br>
           INTEL_FIREVERTICES(intel);<br>
<br>
       intel-&gt;need_throttle = GL_TRUE;<br>
<br>
       if (intel-&gt;batch.used)<br>
           intel_batchbuffer_flush(intel);<br>
   } /* ...and this */<br>
}<br>
<br>
As I commented above, the patch just adds two lines, which just do a<br>
NULL pointer safety check.<br>
<br>
So, generic instructions would be:<br>
<br>
    - get your distro&#39;s newest mesa source package<br>
    - unpack it (e.g. RPMs are really cpio archives)<br>
    - track down the intel_screen.c file and patch (or manually<br>
      edit) it as described above<br>
    - re-package the mesa source package<br>
    - use your distro&#39;s source package build tool to build a binary<br>
      package (e.g. rpmrebuild for RPM-based distros)<br>
<br>
Working with your distro&#39;s source packages should be well-documented<br>
(at least for major distros like Ubuntu and Fedora).<br>
<br>
The other option is to wait: I also reported my success with this on<br>
the elrepo mailing list.  The elrepo mesa maintainer said he didn&#39;t<br>
want to update the package with a patch that wasn&#39;t committed<br>
(according to this thread, it is now, but wasn&#39;t when I made the<br>
comment).  So I would imagine that package maintainers will probably<br>
be open to incorporating this patch into their builds now that it&#39;s<br>
officially committed... I might request it for elrepo if I get<br>
around to it.<br>
<br>
In other words, with this patch officially committed, it will<br>
eventually make its way into different distro&#39;s mesa builds.<br>
<br>
HTH,<br>
Matt<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br>
</div></div></blockquote></div>The latest debug using the latest master.<br>Terminal capture<br><br><a href="http://dl.dropbox.com/u/17574275/mythBacktrace%201-31-12">http://dl.dropbox.com/u/17574275/mythBacktrace%201-31-12</a><br>

<br>gdb.txt<br><br><a href="http://dl.dropbox.com/u/17574275/gdb%201-28-12.txt" target="_blank">http://dl.dropbox.com/u/17574275/gdb%201-31-12.txt</a><br><br>myth.log<br><br><a href="http://dl.dropbox.com/u/17574275/myth%201-31-12.log">http://dl.dropbox.com/u/17574275/myth%201-31-12.log</a><br>