All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlo Wood <carlo@alinoe.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Jones <davej@redhat.com>,
	linux-kernel@vger.kernel.org, eric@anholt.net,
	zhenyu.z.wang@intel.com, lethal@linux-sh.org,
	y-goto@jp.fujitsu.com
Subject: Re: 2.6.22-rc5 regression
Date: Wed, 20 Jun 2007 15:11:20 +0200	[thread overview]
Message-ID: <20070620131120.GA17615@alinoe.com> (raw)
In-Reply-To: <alpine.LFD.0.98.0706191649160.3593@woody.linux-foundation.org>

On Tue, Jun 19, 2007 at 05:09:10PM -0700, Linus Torvalds wrote:
> Heh.
> 
> Yeah, at this point I think we can pretty much guarantee that your problem 
> is one of two cases:
> 
>  - either a bit random, and depends on some timing thing, and one of the 
>    kernels you marked "good" wasn't really.

Nope

>    It's not likely that you marked a good kernel bad, of course, since 
>    with a good kernel, everything should have always worked, but with a 
>    bad kernel and a bug that isn't entirely reproducible, you'd mark it 
>    "good" by mistake - because it just randomly didn't show the problem.

Nope

> OR
> 
>  - we actually have two different commits that introduce the problem for 
>    you, and it comes and goes, and the bisection doesn't work, because 
>    there isn't a clear "this side works, that other side does not" 
>    situation.

Yes

Looking a bit closer to the bisect myself, I note that 
25971f68d392f1816e21520e9e59648403b0bdad and
aba297927d1d558c7a94548135133bdf9172708a are part of
a branch that is derived from a very "old" revision.
git bisect assumes that such an old revision is good,
but in fact - that was already bad as well, because
the history of this bug is:

2.6.22-rc5 BAD
2.6.22-rc4+somethingelse BAD
2.6.22-rc4+something GOOD
2.6.22-rc4 BAD
...
2.6.18-rc1 BAD
2.6.18 GOOD

Thus: BAD BAD BAD GOOD GOOD BAD BAD

and git bisect can't handle that, even though I started
with a 'good' start point and a bad start point at the end.

> For example, later on you say:
> 
> > Personally I am convinced that the real problem is with
> > 8888985144db8f4cb7e56154b31bdf233d3550bf
> 
> but if you look at your commit log, you have:
> 
> > # bad: [25971f68d392f1816e21520e9e59648403b0bdad] [PARISC] fix section
> > # mismatch in ccio-dma
> > git-bisect bad 25971f68d392f1816e21520e9e59648403b0bdad
> 
> Notice? You said that 25971f68d392f1816e21520e9e59648403b0bdad was bad, 
> but that is *before_ the 8888985144db8f4cb7e56154b31bdf233d3550bf commit. 
> Do a
> 
> 	gitk 25971f68d3..8888985144
> 
> to see that part of the history.

This part is thus based upon a revision so old that it was bad again,
even before the small period that it was good.

> So maybe you didn't test that kernel properly? And maybe it really is 
> random, and something has happened that just makes it happen more often?

No, it is really 100% reproducible.

-- 
Carlo Wood <carlo@alinoe.com>

  reply	other threads:[~2007-06-20 13:12 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-17 18:22 2.6.22-rc5 regression Carlo Wood
2007-06-17 19:58 ` Carlo Wood
2007-06-17 21:49   ` Carlo Wood
2007-06-17 23:18     ` Paul Mundt
2007-06-18  0:10       ` Carlo Wood
2007-06-18  0:25         ` Paul Mundt
2007-06-18  7:01           ` Sean
2007-06-18 17:01     ` Linus Torvalds
2007-06-18 18:12       ` Carlo Wood
2007-06-18 18:15         ` Carlo Wood
2007-06-18 18:35         ` Linus Torvalds
2007-06-18 19:54           ` Carlo Wood
2007-06-18 20:42             ` Linus Torvalds
2007-06-18 22:30               ` Daniel Barkalow
2007-06-18 22:50               ` Carlo Wood
2007-06-18 22:57                 ` Linus Torvalds
2007-06-19 23:37                   ` Carlo Wood
2007-06-19 23:44                     ` Dave Jones
2007-06-20  0:09                     ` Linus Torvalds
2007-06-20 13:11                       ` Carlo Wood [this message]
2007-06-20 13:31                         ` Carlo Wood
2007-06-20  1:15                     ` Wang Zhenyu
2007-06-20  1:42                       ` Wang Zhenyu
2007-06-20 14:02                         ` Carlo Wood
2007-06-20 15:46                           ` Wang Zhenyu
2007-06-21  5:43                             ` [PATCH][AGPGART] intel_agp: don't load if no IGD and AGP port Wang Zhenyu
2007-06-21 16:10                               ` Carlo Wood
2007-06-22  0:55                                 ` Wang Zhenyu
2007-06-23 16:52                               ` Andrew Morton
2007-06-23 18:42                                 ` Dave Jones
2007-06-23 18:50                                   ` Andrew Morton
2007-06-23 19:06                                     ` Dave Jones
2007-06-25  1:01                                     ` Wang Zhenyu
2007-06-20 13:22                       ` 2.6.22-rc5 regression Carlo Wood
2007-06-20 13:58                       ` Carlo Wood

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20070620131120.GA17615@alinoe.com \
    --to=carlo@alinoe.com \
    --cc=davej@redhat.com \
    --cc=eric@anholt.net \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=y-goto@jp.fujitsu.com \
    --cc=zhenyu.z.wang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.