<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [IVB, SNB, HSW]I-G-T/gem_cacheing && gem_cpu_concurrent_blit failed" href="https://bugs.freedesktop.org/show_bug.cgi?id=57934#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [IVB, SNB, HSW]I-G-T/gem_cacheing && gem_cpu_concurrent_blit failed" href="https://bugs.freedesktop.org/show_bug.cgi?id=57934">bug 57934</a> from <a class="email" href="mailto:daniel@ffwll.ch" title="Daniel Vetter <daniel@ffwll.ch>"> Daniel Vetter</a> <pre>Just to check: Does reverting commit 7c7b4d55fb69f679c27f8ed056c6f304cd69c3b3 Author: Mika Kuoppala <<a href="mailto:mika.kuoppala@linux.intel.com">mika.kuoppala@linux.intel.com</a>> Date: Tue Dec 4 15:12:05 2012 +0200 drm/i915: Set initial seqno value close to wrap boundary To gain confidence in the wrap handling, make it happen quite soon after the boot. Signed-off-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@ffwll.ch">daniel.vetter@ffwll.ch</a>> Fix the issues again? btw, when adding bisect results, please cite the commit that introduce the regression like above, since that's the most important thing for us. Only if the bisect turns out to not be stable do we look at the bisect log to figure out where the bisect might have gone wrong. I'll update BKMs.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>