How it works
184.108.40.206 is working fine and the problem occurs with the 220.127.116.11 upgrade. Let there be 8 patches between 18.104.22.168 and 22.214.171.124. When you start to bisect, it enables only half of those patches and you build a kernel with 4 of the 8 patches between those two versions.
Now you boot your new compiled kernel and see if you can reproduce the problem. If the kernel is good you take the second half of those 8 patches to build the next kernel, if the kernel is bad you take half of the patches used to narrow down on the patch that causes problems.
For this given example, here is what might happen to find the bad patch (each step you have to build the kernel and reboot into it). We call the patches 1,2,3,4,5,6,7,8:
- 126.96.36.199 + 1,2,3,4
- bad → 188.8.131.52 + 1,2
- good → 184.108.40.206 + 3,4
- bad → 220.127.116.11 + 3
- bad → patch 3 it is!
Step by step example to bisect Linux-2.6.39.
Get the git sources
Get the git sources for the branch you are using:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable
This creates the folder /usr/src/linux-stable.
There are two branches:
- linux-stable.git = sys-kernel/gentoo-sources or sys-kernel/vanilla-sources
- linux.git = sys-kernel/git-sources
This process might take a long time, current size of the git repository is about 500MB.
Link the new sources
Create the symbolic link to the git sources in /usr/src, mount /boot (if needed) and change into the folder:
ln -s linux-stable linux
Once here we need to start bisect and tell him which kernel version works and which doesn't. In our example 18.104.22.168 has no problems and 22.214.171.124 contains a bad patch. The name could also contain an -rcX at the end, which means it's a release candidate, you would have to append that like v126.96.36.199-rc3. I use tee to log every output of bisect into the file bisect.log.
git bisect start | tee -a /root/bisect.log
git bisect bad v188.8.131.52 | tee -a /root/bisect.log
git bisect good v184.108.40.206 | tee -a /root/bisect.log
Try to narrow the versions down as much as possible before starting the bisect, you might need to recompile the kernel a lot of times otherwise.
Build the kernel
Now compile your kernel as usual using e.g. genkernel or just make to build it and anything you might need to boot, like initramfs for LVM, Raid etc. Here is the normal method using make.
cp ../linux-220.127.116.11/.config .
make -j4 && make modules_install && make install
Once booted into the new kernel (make sure your bootloader is booting the new kernel), test, if the problem still perists. In this example we assume the problem is still there, so we tell bisect. It will now take half the used patchset and we have to build our next kernel.
git bisect bad | tee -a /root/bisect.log
Goto #Build the kernel
Now test again and let's say this time the problem is gone, so we tell bisect, build the next kernel and reboot.
git bisect good | tee -a /root/bisect.log
Goto #Build the kernel
87cc4d1e3e05af38c7c51323a3d86fe2572ab033 is the first bad commit commit 87cc4d1e3e05af38c7c51323a3d86fe2572ab033 Author: Chris Wright <firstname.lastname@example.org> Date: Sat May 28 13:15:04 2011 -0500 intel-iommu: Dont cache iova above 32bit commit 1c9fc3d11b84fbd0c4f4aa7855702c2a1f098ebb upstream. Mike Travis and Mike Habeck reported an issue where iova allocation would return a range that was larger than a device's dma mask. https://lkml.org/lkml/2011/3/29/423
With this information, you can create a bug report at bugs.gentoo.org and tell the developers what patch causes problems. The bisect.log file can be attached to the bug report.
If you did not create the logfile, you can use the following command to create some log output.
git bisect log
If you get stuck somewhere or made a mistake, you can reset.
git bisect reset