KernelBisection

Revision 1 as of 2011-01-21 21:56:20

Clear message

This page is under development

Finding a bad commit among a large number of them

The problem

You have made a release, and something broke. There are hundreds of patches committed since the previous tested release. How do you identify the bad one?

Getting set up

Have your tools working and a local repo (how to set up for the Maverick example)

be able to build kernels, on a fast build machine if available

have a reproducer, or have a cooperative tester in the community.

This process can take a lot longer if you have to wait for builds and testing.

What is bisection?

It's a successive splitting of a series of commits in order to locate the single one that caused a failure.

It will take a maximum of n build&test cycles to find the problem . . .

Check out your tree and get ready

git fetch git checkout -b bisecting origin/master

Take a look first to see what you can learn

git log --oneline drivers/gpu/gdm/radeon

Is the problem limited to a subsystem? (radeon in this example) Examine the commits to that subsystem.

Is it obvious where the problem might be?

  • If so, it's worth just reverting that patch and testing.

Determine the known good and known bad commits

In the Maverick case, these are the release tags.

==

Shortcuts

If you can determine a set of commits that are known good and known bad within the larger range, you can reduce the number of iterations required. (explain when this might make sense)