[ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1

[ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1

[Russell King]

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:

Re: [ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1

[Russell King]

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:

Re: [ARM] Regression somewhere between 2.6.19 and 2.6.19-rc1

[Linus Torvalds]

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