Re: [bug] SLUB + mm/slab.c boot crash in -rc9

[Linus Torvalds]

On Tue, 15 Apr 2008, Ingo Molnar wrote:
> 
> quite. Here are all the successfull bootups from my (failed) bisection 
> attempt:
> 
>  0773769191d943358a8392fa86abd756d004c4b6
>  21af0297c7e56024a5ccc4d8ad2a590f9ec371ba
>  26b8256e2bb930a8e4d4d10aa74950d8921376b8
>  2a10e7c41254941cac87be1eccdcb6379ce097f5
>  3aa88cdf6bcc9e510c0707581131b821a7d3b7cb
>  49914084e797530d9baaf51df9eda77babc98fa8
>  53a6e2342d73d509318836e320f70cd286acd69c
>  5be3bda8987b12a87863c89b74b136fdb1f072db
>  6d5f718a497375f853d90247f5f6963368e89803
>  7272dcd31d56580dee7693c21e369fd167e137fe
>  77de2c590ec72828156d85fa13a96db87301cc68
>  82cfbb008572b1a953091ef78f767aa3ca213092
>  b75f53dba8a4a61fda1ff7e0fb0fe3b0d80e0c64
>  c087567d3ffb2c7c61e091982e6ca45478394f1a
>  d4b37ff73540ab90bee57b882a10b21e2f97939f
>  fde1b3fa947c2512e3715962ebb1d3a6a9b9bb7d

Ok, can you try this script

	git bisect start
	git bisect bad 7fa2ac3728ce828070fa3d5846c08157fe5ef431
	git bisect good 0773769191d943358a8392fa86abd756d004c4b6
	git bisect good 21af0297c7e56024a5ccc4d8ad2a590f9ec371ba
	git bisect good 26b8256e2bb930a8e4d4d10aa74950d8921376b8
	git bisect good 2a10e7c41254941cac87be1eccdcb6379ce097f5
	git bisect good 3aa88cdf6bcc9e510c0707581131b821a7d3b7cb
	git bisect good 49914084e797530d9baaf51df9eda77babc98fa8
	git bisect good 53a6e2342d73d509318836e320f70cd286acd69c
	git bisect good 5be3bda8987b12a87863c89b74b136fdb1f072db
	git bisect good 6d5f718a497375f853d90247f5f6963368e89803
	git bisect good 7272dcd31d56580dee7693c21e369fd167e137fe
	git bisect good 77de2c590ec72828156d85fa13a96db87301cc68
	git bisect good 82cfbb008572b1a953091ef78f767aa3ca213092
	git bisect good b75f53dba8a4a61fda1ff7e0fb0fe3b0d80e0c64
	git bisect good c087567d3ffb2c7c61e091982e6ca45478394f1a
	git bisect good d4b37ff73540ab90bee57b882a10b21e2f97939f
	git bisect good fde1b3fa947c2512e3715962ebb1d3a6a9b9bb7d

and then you'll apparently hit that commit you had compile problems
with.  HOWEVER, at that point, just do

	git bisect visualize

and pick a commit somewhere roughly half-way that you suspect is a good 
point of testing, but not near the range that you had problems with.  If 
you have compile problems in the middle, pick something that is just one 
third down, for example. It will make the bisection slower, but 
considering how unable we've been to make much progress other ways, if we 
can narrow it down from 1874 commits to something smaller, I suspect we'll 
be much happier.

Then you just do

	git checkout <sha-you-picked-out-here>

and compile that one, and check. 

Besides, while the _optimal_ point is half-way, even if you only remove a 
third or a quarter of the commits at each stage, it's still going to be 
an exponential thing.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/