fixed 689268 linux-2.6/3.3~rc6-1~experimental.1
forcemerge 689268 692234
quit

Ingo wrote:

> I have now been running kernel 3.3.0-rc6-amd64 for 4 days. I did even
> try with different BIOS settings for "IGD DVMT Memory" especially with
> "Maximum DVMT" which according to the manual corresponds to 1.7GB. With
> this configuration I did have freezes few times a day with Wheezy stock
> kernel before.
>
> This is *fixed in kernel 3.3.0-rc6-amd64*. All is 100% stable.

That's a comfort.  Thanks for checking.

> Do you want me to continue with this test?

No, please use whatever kernel is most convenient for now.  Hopefully
we will find some patch to test against 3.2.y soon.

Per found a similar result: 3.3-rc6 working, 3.2.y failing, so I'm
merging the bugs to keep them easier to keep track of.  Per also found
that using the GPU driver from 3.2.y with everything else from 3.3-rc6
still seems to work fine, so we'll have to find some other way to
isolate the failing component.

If you have time to bisect to find the fix, that would be excellent.
Bisecting to find a regression is described at [1].  Finding a fix is
a little more confusing --- here are some instructions.  Remember that
a "good" kernel here is a kernel that successfully freezes, and a
"bad" kernel is one that works stably, so to find the "first bad
commit" is to find the fix.

 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. configure, build, test:
        cd linux
        git checkout v3.2
        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
        ... test test test ...

    Hopefully it successfully reproduces the freeze.  So tell git about
    it:

        cd linux
        git bisect start
        git bisect good; # reproduced the freeze

 3. establish upper bound:
        git checkout v3.3-rc6
        make deb-pkg; # maybe with -j4
        dpkg -i ../<name of package>; # as root
        reboot
        ... test test test ...

    Hopefully it does not reproduce the freeze, so tell git:

        cd linux
        git bisect bad

 4. a revision halfway between is automatically checked out to test.
        cd linux
        make deb-pkg; # maybe with -j4
        dpkg -i ../<name of package>; # as root
        reboot
        ... test test test ...

     Tell git the result:
        git bisect good; # if it reproduces the freeze
        git bisect bad; # if it reliably does not (is stable)
        git bisect skip; # if some other bug makes it hard to test

 5. repeated until it prints the "first bad commit" or until bored.
    If you have the gitk package installed, at any step you can run
        git bisect visualize

    to watch the range with the fix narrowing, or
        git bisect log

    to produce a log others can use to pick up where you left off.
    Since this bug is hard to reliably reproduce, we'll want this
    log at the end anyway.

Thanks,
Jonathan

[1] http://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2.1


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121108155518.GB21042@elie.Belkin

Reply via email to