I'm seeing utterly random behaviour from kernels on ARM SMP hardware
built after 2.6.19. I won't bother trying to paste the kernel output;
sometimes the kernel locks solid (no IRQs, no output to say what's wrong).
Other times I get the first line of an oops repeating but with random
addresses. Othertimes the oops doesn't complete.
2.6.19 runs fine.
So I just tried using git bisect to track down the problem. First issue
that presky cmpxchg() causing a build error. Ok, so I provide a version
to get around that.
Next problem:
fs/proc/proc_misc.c: In function `version_read_proc':
fs/proc/proc_misc.c:256: warning: implicit declaration of function `utsname'
fs/proc/proc_misc.c:256: error: invalid type argument of `->'
fs/proc/proc_misc.c:256: error: invalid type argument of `->'
make[3]: *** [fs/proc/proc_misc.o] Error 1
make[2]: *** [fs/proc] Error 2
make[1]: *** [fs] Error 2
make: *** [uImage] Error 2
It seems this breakage seems to have been introduced some 260-odd commits
prior to the point which git bisect wants me to test.
How do I tell git bisect "I can't test this, this is neither good nor bad,
please choose another to try" ? Or is git bisect hopeless given the large
amount of unbuildable commits thanks to our weekly merges?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, Jan 02, 2007 at 04:39:23PM +0000, Russell King wrote:
> I'm seeing utterly random behaviour from kernels on ARM SMP hardware
> built after 2.6.19. I won't bother trying to paste the kernel output;
> sometimes the kernel locks solid (no IRQs, no output to say what's wrong).
> Other times I get the first line of an oops repeating but with random
> addresses. Othertimes the oops doesn't complete.
>
> 2.6.19 runs fine.
>..
> How do I tell git bisect "I can't test this, this is neither good nor bad,
> please choose another to try" ? Or is git bisect hopeless given the large
> amount of unbuildable commits thanks to our weekly merges?
Don't worry - viro suggested changing the problematical two strings, which
allowed me to test that commit.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Tue, 2 Jan 2007, Russell King wrote:
>
> How do I tell git bisect "I can't test this, this is neither good nor bad,
> please choose another to try" ? Or is git bisect hopeless given the large
> amount of unbuildable commits thanks to our weekly merges?
The easiest way to do this is to start off with
git bisect visualize
which will just show you all the potentially interesting commits, and you
can just browse it for commits that you deem to be (a) ok to try and (b)
hopefully _somewhat_ central to bisection (ie if you pick something that
is very close to one of the already-checked points, the efficiency of
bisection drops a lot - it will still _work_, but if it's not "near the
middle of the pack" it simply won't be very efficient any more.
And then just do
git reset --hard <hand-picked-point>
and off you go. Compile, test, and do "git bisect bad/good" (at which
point "git bisect" will again pick a half-way point automatically for you,
but hopefully you'll have gotten out of the problematic region so you
don't need to override it by hand any more. But you _can_ always override
it, of course).
You can also use the "git reset --hard xyzzy" overrides in case you have a
suspicion about where things happen, and you want to narrow things down by
hand by testing a point closer to the suspicious area. Usually the
bisection is very efficient, but if you have a good clue where the problem
happens, pointing in the right direction and trying to force bisection to
look at a special place will obviously help further.
Of course, if your "good clue" was actually garbage, you'll just make
bisection take longer instead ;)
Linus