Yes, Yinghai's first response when I tried his 2.6.27-rc3 patch and the 
kernel still locked was "there is some other problem" (besides the changes
in 3def3d6d).

You may have misunderstood my meaning:  I was only saying that a further
experiment of mine showed that 3def3d6d... alone is not the problem, so
that trying to undo the changes from that commit all the way up near the
git HEAD was unlikely to work.  I did not mean that his patch was a bad
idea, or that it should not have been tried.  When Yinghai created that 
patch, I had not yet done that experiment.  I was just offering an 

I am convinced this is the case, as a result of a bisection I performed
Wednesday night -- where I tried to revert the 3def3d6d changes alone in
kernel revisions much closer to that commit, only to discover that the

Thank you *very* much for this suggestion, Mike!  I am an "end user," not
a developer, so I never would have thought of this.

Your explanation of how to carry out this bisect process is very much like
the process I used on Wednesday night.  The only difference is that I 
manually edited the 3 files involved at each step, instead of trying to
patch using the 3def3d6d diff.  I can see that your way would have been
much easier, as long as I am careful to watch for rejected patches.

I have to go to work for a few hours, but should be able to put a lot of

Ahh, this is the experiment I performed Wednesday night.  The results:
3def3d6d is not the true cause.  Beginning with 3def3d6d..., it looks
like anything that touches insert_resource() causes kernels to lock up
on my two ECS AMD690GM-M2 mboards, but not on my other machine (or your

No such luck.  Can you say, "Preparation H"?  (I know I can....)


Thanks Mike,
Dave W.
--

[ message continues ]