Re: HPET regression in 2.6.26 versus 2.6.25 -- why Yinghai's revert may have failed

[David Witbrodt <dawitbro@sbcglobal.net>]

> > 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.