How it works
18.104.22.168 is working fine and the problem occurs with the 22.214.171.124 upgrade. Let there be 8 patches between 126.96.36.199 and 188.8.131.52. 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:
- 184.108.40.206 + 1,2,3,4
- bad → 220.127.116.11 + 1,2
- good → 18.104.22.168 + 3,4
- bad → 22.214.171.124 + 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:
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
Link the new sources
Create the symbolic link to the git sources in /usr/src, mount /boot (if needed) and change into the folder:
Once here we need to start bisect and tell him which kernel version works and which doesn't. In our example 126.96.36.199 has no problems and 188.8.131.52 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 v184.108.40.206-rc3. I use tee to log every output of bisect into the file bisect.log.
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.
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.
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.
Goto #Build the kernel
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.
If you get stuck somewhere or made a mistake, you can reset.