<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [BAT] [HSW] igt@gem_exec_parallel@basic fails" href="https://bugs.freedesktop.org/show_bug.cgi?id=100052#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [BAT] [HSW] igt@gem_exec_parallel@basic fails" href="https://bugs.freedesktop.org/show_bug.cgi?id=100052">bug 100052</a> from <a class="email" href="mailto:daniel@ffwll.ch" title="Daniel Vetter <daniel@ffwll.ch>"> Daniel Vetter</a> <pre>Nothing in the merge commit, so likely an interaction between too patches. The way to figure this out is probably with bisecting which additional patch breaks stuff: $ git bisect start $ git bisect good $first_parent $ git bisect bad $merge_commit Then create a separate git repo, and for every sha1 that bisect wants you to test do: $ git reset --hard $first_parent $ git merge $sha1_to_test Then run your testcase, go back to the other git checkout where you do the bisecting and report the result. That should give you you an offending commit somewhere in the branch for the 2nd parent. If you then do it the other way round you will find the offending patch in the 1st parent. Those two should then be the 2 patches which interact in a bad way somehow, and probably explain the bug. A more effective way might be to do a full git imerge on both branches, and run the bisect over that. But that's even more fancy ...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>