mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome