User:Ignatenkobrain/Kernel/Bisection

About

All packaged kernels for testing you can download from koji 3.9.9 is working fine and the problem occurs with the 3.10.9 upgrade. Let there be 8 patches between 3.9.9 and 3.10.9. 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:

• 3.9.9 + 1,2,3,4
• bad → 3.9.9 + 1,2
• good → 3.9.9 + 3,4
• bad → 3.9.9 + 3
• bad → patch 3 it is!

Prepare

Installing git:

# yum install git -y

Usage

Get the git sources

$ cd ~

• Problem with release candidates or with unstable:

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

• Problem with stable kernels:

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux

$ cd linux

This creates the folder /usr/src/linux-stable

Start bisect

$ git bisect start
$ git bisect bad v3.10.9
$ git bisect good v3.9.9

Build the kernel

$ export MAKEOPTS="`rpm --eval %{?_smp_mflags}`"
$ curl http://pkgs.fedoraproject.org/cgit/kernel.git/plain/config-generic > .config
$ curl http://pkgs.fedoraproject.org/cgit/kernel.git/plain/config-`arch`-generic >> .config
$ make oldconfig
$ make bzImage && make modules 
# make modules_install && make install

• BIOS:

# grub2-mkconfig -o /boot/grub2/grub.cfg

• UEFI:

# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Reboot:

# systemctl reboot

Testing problem..

Bad bisect

$ cd ~/linux
$ git bisect bad

Goto #Build the kernel

Good bisect

$ cd ~/linux
$ git bisect good

Goto #Build the kernel

Unknown bisect

$ cd ~/linux
$ git bisect skip

Goto #Build the kernel

Final bisect

You repeat those steps #Bad bisect and #Good bisect until it shows the content of the bad patch, like shown below (there is more text in the output, this is just half of it).

87cc4d1e3e05af38c7c51323a3d86fe2572ab033 is the first bad commit
commit 87cc4d1e3e05af38c7c51323a3d86fe2572ab033
Author: Chris Wright <chrisw@sous-sol.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 RHBZ and tell the developers what patch causes problems. The bisect.log file can be attached to the bug report.

Log file

$ cd ~/linux
$ git bisect log > ~/bisect.log

Reset bisect

If you get stuck somewhere or made a mistake, you can reset.

$ cd ~/linux
$ git bisect reset