LKML Archive on
help / color / mirror / Atom feed
From: Linus Torvalds <>
To: Helge Deller <>
Cc: Jiri Slaby <>,
	Andrew Morton <>,
	Jiri Kosina <>,,,,,
Subject: Re: Who broke cb8f488c33 patch? (was Re: [PATCH 1/1] USBHID: correct start/stop cycle)
Date: Thu, 13 Nov 2008 08:22:47 -0800 (PST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 13 Nov 2008, Helge Deller wrote:
> I bisected twice. Both times I found this one to be the culprit.
> Nevertheless, just reverting this (Thanks Denys!) didn't fixed the USB
> problem.

The trivial bisecting approach doesn't work if there are two independent 
bugs that have overlapping lifetimes. In fact, bisection doesn't 
necessarily work even if the lifetimes of the bugs are clearly disjoint, 
because then if you look for bug A, but mark something "bad" because of 
bug B, it can easily end up zeroing in on the wrong cause.

So "git bisect" is an absolutely wonderful tool, but it does require you 
to be able to be sure about _which_ exact bug you chase down to give 
reliable answers.

In the presense of multiple bugs, you have two choices:

 (a) either you have to know how to distinguish them reliably in order to 
     give a clean good/bad for the particular bug you are chasing.

     This can be impossible: one bug may make it impossible to even _test_ 
     for the other bug, eg a bug that prevents bootup will obviously make 
     it impossible to see whether an independent run-time bug exists or 
     not. In this case, you have to do (b)

 (b) Find _one_ bug first (doesn't matter which), and fix it. And then, do 
     a second bisection run, but before each test, you may need to apply 
     the fix for the first bug, so that you know that's not the an issue.

     This can be automated (check if the broken commit is in the current 
     tree to be tested, apply a patch to fix it if it is), but it's not as 
     simple as just saying "let's bisect".

So bisection with multiple bugs is certainly possible, but it's also 
unquestionably a lot more work, and more complicated.


  reply	other threads:[~2008-11-13 16:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-01 22:41 [PATCH 1/1] USBHID: correct start/stop cycle Jiri Slaby
2008-11-01 23:02 ` Jiri Kosina
2008-11-01 23:07   ` Jiri Slaby
2008-11-02 10:43     ` Helge Deller
2008-11-02 10:55       ` Jiri Slaby
2008-11-02 16:50         ` Helge Deller
2008-11-02 19:24           ` Denys Vlasenko
2008-11-11 23:22             ` Jiri Kosina
2008-11-12  0:24               ` Denys Vlasenko
2008-11-12  0:34                 ` Who broke cb8f488c33 patch? (was Re: [PATCH 1/1] USBHID: correct start/stop cycle) Jiri Kosina
2008-11-12  0:50                   ` Andrew Morton
2008-11-12  9:23                     ` Jiri Slaby
2008-11-13 15:32                       ` Helge Deller
2008-11-13 16:22                         ` Linus Torvalds [this message]
2008-11-11 22:52 ` [PATCH 1/1] USBHID: correct start/stop cycle Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: Who broke cb8f488c33 patch? (was Re: [PATCH 1/1] USBHID: correct start/stop cycle)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).