<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - [IVB regression] Screen corruption since Kernel 3.9 (+ 3.10) with HD 4000 on H77 Board HDMI to DVI" href="https://bugs.freedesktop.org/show_bug.cgi?id=68535#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO --- - [IVB regression] Screen corruption since Kernel 3.9 (+ 3.10) with HD 4000 on H77 Board HDMI to DVI" href="https://bugs.freedesktop.org/show_bug.cgi?id=68535">bug 68535</a> from <a class="email" href="mailto:daniel@ffwll.ch" title="Daniel Vetter <daniel@ffwll.ch>"> Daniel Vetter</a> <pre>(In reply to <a href="show_bug.cgi?id=68535#c9">comment #9</a>) > Short question. I'm running the bisecting process currently. I'm down to > roughly 4 turns to do. Now i have a build which "solves" the issue of this > bug but adds a new issue while starting the X server. > > So my question is should i proceed with "git bisect good" because the KMS is > working with this bisect build or should i proceed with "git bisect bad" > because the X server doesn't start (= system freeze) with this bisect build? If you can't properly test a commit (which is a bit the case here since it's unclear) you can $ git bisect skip If we're lucky the real issue is somewhere else in the history. If not we can analyze things later on precisely. But just skipping avoids that we mislead the bisect process into a deadend if we make the wrong call.</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>