The absolutely most helpful thing you could do (and it really isn't that
complex, just somewhat time-consuming) is to do a "git bisect" to figure
out exactly where it started.
"git bisect" is really simple to run, and since you know a start-point and
an end-point, and they aren't even all _that_ far away from each other,
it's going to be reasonably quick.
The fact that you have tested only -rc release kernels makes me suspect
you aren't a git user, but don't worry, it's really quite easy.
Just make sure you have git installed (most distros have it, so a "yum
install git-core" or something like that should do it), and then do
# get the kernel repo
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
cd linux-2.6
# start bisecting
git bisect start
git bisect good v2.6.34-rc3
git bisect bad v2.6.34-rc4
and git will look at the good/bad pair you told it, and try to find a
mid-point between the two. It will say something like this:
Bisecting: 288 revisions left to test after this (roughly 8 steps)
[14e71e4fb94c340273534a6d7f210aa82a3ca717] Merge git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog
which just means that there were roughly 2*288=576 commits (584 to be
exact - since history isn't linear, it couldn't find an _exact_ mid-point)
between -rc3 and -rc4, and it has checked out a midpoint for you to try.
Now, just compile that kernel version, install it, and try to boot it.
If it works, you tell git so with "git bisect good" and it will pick a new
kernel for you to test (now half-way between that _new_ good kernel and
the bad kernel). And if it _doesn't_ work, just tell git so with "git
bisect bad", and it will pick another kernel for you to test.
You'll end up having to test maybe nine or ten kernels, but then git will
tell you exactly which commit caused your problem.
Alternatively, if you find the process really tedious (I admit that it is
tedious, but the nice thing is that it's straightforward and doesn't
require you to know what the bug is) and don't have the time or energy to
test nine or ten kernels, if you can do a bisect of even just four or five
kernels and then post the resulting ".git/BISECT_LOG" file, that will
already help a lot. It will narrow down the 584 commits down to just a
fraction (if you test 5 bisect-points, it should narrow it down to roughly
~20 commits or so: each bisect point roughly splits the thing in half).
Linus
--
