Re: Linux 2.6.25-rc4

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Monday 10 March 2008, Anders Eriksson wrote:
> 
> bzolnier@gmail.com said:
> >> The bisect came up with this:
> >> 
> >> 18a056feccabdfa9764016a615121b194828bc72 is first bad commit
> >> commit 18a056feccabdfa9764016a615121b194828bc72
> 
> > Hmm, this is the first commit _after_ the previous "guilty" commit
> > 852738f39258deafb3d89c187cb1a4050820d555 so it just can't be the "real bad"
> > one... 
> 
> I share the same worry. Towards the end of the bisect run (something like the
> 4-th last reboot), I was asked to try "2.6.24". Now, I _thought_ 2.6.24 was way
> before 852738f39258deafb3d89c187cb1a4050820d555, and hence it should be called
> 2.X.Y-foobaz something as the others were. Is this the way it should be, or did
> I fscked up the bisect?

8527 was merged before -rc1 so it is expected that resulting kernel was
called 2.6.24 (though it wasn't really 2.6.24) if CONFIG_LOCALVERSION_AUTO
config option is disabled (it is useful to have it enabled).

> This was a bisect run between 852738f39.. and 2.5.25-rc1. I got a string of 
> "bad"s but TWO goods, actually. Those goods sustained a number of reruns of 
> smartd (I can share the BISECT_LOG if wanted).
> 
> And how we can end up with good_start+1 as the guilty one, and STILL have two 
> good ones during the bisect run..... That's beyond me. lets just say that my 
> faith in myself and/or bisect starts to decline...
> 
> Now I'm considering a 2.6.24 .. 8527 run.

This is worth a try but please remember that the problem may not show up
immediately so it would require few tests to verify each commit (it is also
possible that the problem won't show up at all if we are unlucky).

Thanks,
Bart