<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [AMD tahiti XT] displayport broken" href="https://bugs.freedesktop.org/show_bug.cgi?id=107784#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [AMD tahiti XT] displayport broken" href="https://bugs.freedesktop.org/show_bug.cgi?id=107784">bug 107784</a> from <a class="email" href="mailto:sylvain.bertrand@gmail.com" title="Sylvain BERTRAND <sylvain.bertrand@gmail.com>"> Sylvain BERTRAND</a> <pre>Got something, sort of obvious for a human, impossible for bisect to know, which explains why this bisection was a failure: testing a commit in the middle of a series of commits which are to be taken as a whole to be consistent for normal operations of the kernel, is wrong. That, bisect cannot know. In my case, the TSC commits are "good"... and testing time has nothing to do with this: testing a commit in the middle of this series will have a side effect (DP link/aux timings...) on what I am observing to decide if a commit is "bad" or "good". In my case it will break this observable (my DP monitor is _really_ not working) and I'll tag the commit as "bad", which is inconsistent. The bottom of this, which is _obvious_ for an experienced git user on large projects, at the time of big merges on the main branch of a project like linux, if something breaks, bisect is probably more your enemy than your friend: it is ok to ask "Can you bisect?" on a sub-sub-system branch which has been free from big merges from any related other subsystems for a good while, but almost an insult on such massive update.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>