The most annoying bugs are those of the „this did already work in the past“ type.

Doing manual bisecting has also been an annoying task in the past. Especially when talking about Kernel bugs which will require frequent reboots.

Fortunately this step, while still somewhat time consuming, got much easier in recent times thanks to two very handy tools. One of them is git, the top-notch revision control system, the other one is virtualisation (virtualbox in my case).

So here is how I search the broken commit using theses tools:

Lets assume we have a problem which we discovered in kernel 3.7 and which did not appear in kernel 3.6.

First get a stable kernel tree if you do not already have one:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Then issue the following 3 commands:

git bisect start
git bisect good v3.7
git bisect bad v3.6

Our source tree is now at a state where we must check if this kernel works or not. For this purpose I usually run Debian’s make-kpkg command which will build a debian package from a given kernel source.

Afterwards install this kernel in your virtual Linux system and reboot the VM.

Login to the VM and check if the bug is present there. If so issue a git bisect bad command, if not call git bisect good.

Repeat these two steps until git tells you exactly which commit did cause the problem.

Now all you need to do is mail the person responsible for the faulty commit 🙂