> > Considering these 3 consecutive commits (according to 'git log')from late
> > Feb. 2008, between kernel versions 2.6.25 and 2.6.26-rc1:
> > ---------------------------------------------------------
> >
> > 700efc1b...: the last kernel I can build and run just fine.
> >
> > 3def3d6d...: this one builds, but locks up in inet_init() once the sequence
> > of function calls reaches synchronize_rcu(). Reverting here works, but is
> > trivial and silly, just reproducing 700efc1b...
> >
> > 1e934dda...: attempting to revert the changes from 3def3d6d... (just one
> > commit before!) already fails.
> > ---------------------------------------------------------
> >
> > This last commit has an effect on my machine that prevents attempts to
> > revert 3def3d6d... from working as intended. This may explain why
> > Yinghai's patch providing the revert for 2.6.27-rc3 did not work.
> > (Hopefully none of the other changes between Feb. and Aug. would also keep
> > the revert from working, but I wouldn't bet my life on it....)
> >
> > The 3d... and 1e... commits are quite small, touching only 4 files total,
> > and both commits involve calls to insert_resource(). Something on my 2
> > problem machines is behaving badly in this area.
>
> I wonder if it would help to revert both the 3def3d6d... and 1e934dda...
> commits. If there are 2 (or more) problematic commits, then of course
> it wouldn't help to revert just one of the two commits. This is one of
> the nastiest type of debugging scenario, when there is more than one
> cause of the observed problem, although in such case the multiple
> causes are often related in some way.
Thanks for this Bill. I got home pretty late last night, so I only tried a
few things before hitting the sack.
Your suggestion is something I was planning, but didn't get to yet. It
seems like any change after 3def3d6d that touches insert_resource() causes
kernels to lock up on 2 of my 3 machines.
Mike Galbraith sent an offlist reply with a very good idea for finding out
whether a commit _before_ 3def3d6d is the actual cause of my troubles. I
am more intrigued by this possibility than the idea you and I had about
reverting both 3def3d6d and 1e934dda and moving forward from there.
If Mike's idea doesn't seem to go anywhere -- if I cannot find a kernel
that works by applying the 3def3d6d changes to _previous_ kernel revisions,
then I plan to create a branch at 700efc1b and try moving forward toward
2.6.26 (skipping the 3def3d6d and 1e934dda commits, of course) until the
kernel freezes again.
Now I have plenty of things to try!
Thx,
Dave W.