Adrian Fita wrote:

> Hi. I tracked the regression between kernel v. 2.6.37-2 [1] (not
> happening) and v. 2.6.38~rc6-1~experimental.1 [2] (happening).
>
>   1: http://snapshot.debian.org/package/linux-2.6/2.6.37-2/
>   2: http://snapshot.debian.org/package/linux-2.6/2.6.38~rc6-1~experimental.1/
>
> What do you recommend next?

Nice.  That narrows it down to one of 104 patches, which means
7 rounds of bisection would narrow it down to a single patch:

 0. prerequisites:

        apt-get install git build-essential

 1. get the kernel history, if you don't already have it:

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

 2. make sure the upstream kernel reproduces the bug:

        cd linux
        cp /boot/config-$(uname -r) .config; # current configuration
        scripts/config --disable DEBUG_INFO
        make localmodconfig; # optional: minimize configuration
        make deb-pkg; # optionally with -j<num> for parallel build
        dpkg -i ../<name of package>; # as root
        reboot

    Hopefully it does.  So:

 4. make sure the older kernel does not reproduce the bug:

        cd linux
        git bisect start -- drivers/acpi
        git bisect bad v2.6.38-rc6
        git checkout v2.6.37
        make silentoldconfig; # reuse configuration
        make deb-pkg; # maybe with -j4
        dpkg -i ../<name of package>; # as root
        reboot
        ... test test test ...
        git bisect good; # mark v2.6.37 as good

 5. a version half-way between is automatically checked out to test:

        make silentoldconfig; # reuse configuration
        make deb-pkg; # maybe with -j4
        dpkg -i ../<name of package>; # as root
        reboot
        ... test test test ...

        git bisect bad; # if it reproduces the bug
        git bisect good; # if it works nicely
        git bisect skip; # if some other bug makes it hard to test

If you go through step 5 enough times, it will reveal the "first bad
commit".  If you get bored before then, running "git bisect log" will
produce a log of the versions you have tested to allow someone else to
pick up where you left off.  If the gitk package is installed, at any
step you can run "git bisect visualize" to watch the regression range
narrowing.

Hope that helps,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to