Re: 2.6.22-rc5 regression

From: Carlo Wood
Date: Wed Jun 20 2007 - 09:12:44 EST


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@xxxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/