From Fedora Project Wiki
 
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
= About =
All packaged kernels for testing you can download from [http://koji.fedoraproject.org/koji/packageinfo?packageID=8 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:
Installing git:
<pre>
<pre>
# yum install git -y
# yum install git -y
</pre>
</pre>
Goto home directory:
 
= Usage =
 
=== Get the git sources ===
<pre>
<pre>
$ cd ~
$ cd ~
</pre>
Clone upstream kernel:
<pre>
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
</pre>
$ git clone http://github.com/ignatenkobrain/kernel-package.git
Goto directory with kernel:
<pre>
$ cd linux
$ cd linux
</pre>
</pre>
Start bisection:
This creates the folder ~/linux
 
=== Start bisect ===
<pre>
<pre>
$ git bisect start
$ git bisect start
Line 21: Line 37:
$ git bisect good v3.9
$ git bisect good v3.9
</pre>
</pre>
Download latest config:
 
=== Build and install the kernel ===
<pre>
<pre>
$ curl http://pkgs.fedoraproject.org/cgit/kernel.git/plain/config-generic > .config
$ cd ~/linux
$ curl http://pkgs.fedoraproject.org/cgit/kernel.git/plain/config-`arch`-generic >> .config
$ ~/kernel-package/kernel-package.py
$ mock -r fedora-19-x86_64 --rebuild sources/*.src.rpm --resultdir sources/rpms
# yum install sources/rpms/*.rpm
</pre>
</pre>
Make new config from downloaded Fedora configs:
 
Reboot and test problem..
 
=== Bad bisect ===
<pre>
<pre>
$ make oldconfig
$ cd ~/linux
$ git bisect bad
</pre>
</pre>
Export flags for smp processor:
Goto [[#Build the kernel]]
 
=== Good bisect ===
<pre>
<pre>
export MAKEOPTS="`rpm --eval %{?_smp_mflags}`"
$ cd ~/linux
$ git bisect good
</pre>
</pre>
Compiling kernel:
Goto [[#Build the kernel]]
 
=== Unknown bisect ===
<pre>
<pre>
$ make bzImage && make modules
$ cd ~/linux
$ git bisect skip
</pre>
</pre>
Install new kernel:
 
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).
<pre>
<pre>
# make modules_install && make install
c630ccf1a127578421a928489d51e99c05037054 is the first bad commit
commit c630ccf1a127578421a928489d51e99c05037054
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date:  Sat Mar 16 19:19:46 2013 +0100
 
    rt2800: rearrange bbp/rfcsr initialization
   
    This makes order of initialization of various registers similar like
    on vendor driver.
   
    Based on:
    NICInitializeAsic()
    RT5592LoadRFNormalModeSetup()
   
    from:
    DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
    DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chip/rt5592.c
   
    Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
 
:040000 040000 69266bfa97e9e808257f9cfa7196f00222410ebf 7e18f08faa95bb3dd7159381d6085e5b5287809c M      drivers
</pre>
</pre>
Update grub:
With this information, you can create a bug report at [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=kernel RHBZ] and tell the developers what patch causes problems. The bisect.log file can be attached to the bug report.
* BIOS:
 
=== Log file ===
<pre>
<pre>
# grub2-mkconfig -o /boot/grub2/grub.cfg
$ cd ~/linux
</pre>
$ git bisect log > ~/bisect.log
* UEFI:
<pre>
# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
</pre>
Reboot:
<pre>
# systemctl reboot
</pre>
</pre>


Testing problem..
=== Reset bisect ===
 
If you get stuck somewhere or made a mistake, you can reset.
Goto directory with linux kernel:
<pre>
<pre>
$ cd ~/linux
$ cd ~/linux
</pre>
$ git bisect reset
Problem still present:
<pre>
$ git bisect bad
</pre>
Problem isn't present:
<pre>
$ git bisect good
</pre>
Kernel doesn't boot or other:
<pre>
$ git bisect skip
</pre>
</pre>

Latest revision as of 07:24, 4 September 2013

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 ~
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git clone http://github.com/ignatenkobrain/kernel-package.git
$ cd linux

This creates the folder ~/linux

Start bisect

$ git bisect start
$ git bisect bad v3.11-rc1
$ git bisect good v3.9

Build and install the kernel

$ cd ~/linux
$ ~/kernel-package/kernel-package.py
$ mock -r fedora-19-x86_64 --rebuild sources/*.src.rpm --resultdir sources/rpms
# yum install sources/rpms/*.rpm

Reboot and test 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). 

c630ccf1a127578421a928489d51e99c05037054 is the first bad commit
commit c630ccf1a127578421a928489d51e99c05037054
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date:   Sat Mar 16 19:19:46 2013 +0100

    rt2800: rearrange bbp/rfcsr initialization
    
    This makes order of initialization of various registers similar like
    on vendor driver.
    
    Based on:
    NICInitializeAsic()
    RT5592LoadRFNormalModeSetup()
    
    from:
    DPO_RT5572_LinuxSTA_2.6.1.3_20121022/common/rtmp_init.c
    DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chip/rt5592.c
    
    Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
    Tested-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

:040000 040000 69266bfa97e9e808257f9cfa7196f00222410ebf 7e18f08faa95bb3dd7159381d6085e5b5287809c M      drivers

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
Retrieved from "https://fedoraproject.org/w/index.php?title=User:Ignatenkobrain/Kernel/Bisection&oldid=351648"