<div dir="ltr">On 6 January 2014 17:05, Chad Versace <span dir="ltr"><<a href="mailto:chad.versace@linux.intel.com" target="_blank">chad.versace@linux.intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Commit 1a92881 added extra flushes to fix a HiZ hang in<br>
WebGL Google Maps. With the extra flushes emitted by the previous two<br>
patches, the flushes added by 1a92881 are redundant.<br>
<br>
Tested with the same criteria as in 1a92881: by zooming in and out<br>
continuously for 2 hours on Sandybridge Chrome OS (codename<br>
Stumpy) without a hang.<br>
<br>
CC: <a href="mailto:mesa-stable@lists.freedesktop.org">mesa-stable@lists.freedesktop.org</a><br>
CC: Kenneth Graunke <<a href="mailto:kenneth@whitecape.org">kenneth@whitecape.org</a>><br>
CC: Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>><br>
CC: Stéphane Marchesin <<a href="mailto:marcheu@chromium.org">marcheu@chromium.org</a>><br>
Signed-off-by: Chad Versace <<a href="mailto:chad.versace@linux.intel.com">chad.versace@linux.intel.com</a>><br>
---<br>
 src/mesa/drivers/dri/i965/gen6_blorp.cpp | 14 --------------<br>
 1 file changed, 14 deletions(-)<br></blockquote><div><br></div><div>I'm baffled by this.  My understanding of patches 1 and 2 is that they both set need_workaround_flush redundantly, so they should have no effect on what is sent to the hardware.  Therefore, it seems like this patch puts us back in the buggy state we were in before commit 1a92881.  Have I missed something in my analysis?<br>
<br>What was the previous MTBF on your system before commit 1a92881?  Is it possible that 2 hours isn't a long enoug test?  (For example, if the MTBF was 40 minutes, and the failures were Poisson-distributed, then I believe that 2 hours without a failure only confirms the bug fix at 95% confidence.)<br>
</div></div></div></div>