fixed 665881 linux-2.6/3.3~rc6-1~experimental.1
found 665881 linux/3.2.35-2
# not fixed in 3.2.y yet
tags 665881 - fixed-upstream
quit
Hans-J. Ullrich wrote:
> I installed linux-image-3.3.0-rc6-amd64_3.3~rc6-1~experimental.1_amd64.deb
> from snapshots.debian.org, and its headers, but the bug never appeared.
>
> I did almos 10 - 15 rebootsx with no appearence of the bug.
>
> Then I started 3.2 kernel and the bug appeared again.
Thanks, Hans. Marking accordingly so we don't forget.
Am I correct in assuming the 3.2 kernel in question is 3.2.35-2?
The next step is for us to ferret out another upstream patch to test.
If you're bored before then, here are instructions for performing a
"reverse bisect" to find when the fix seems to have been introduced.
These instructions will probably be confusing: remember that a "good"
kernel is one that successfully reproduces the bug, while a "bad" one
is one that does not reproduce it.
0. get the kernel history, if you don't already have it:
git clone \
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
1. initialize the bisection, configure, build, test:
cd linux
git bisect start
git checkout v3.2
cp /boot/config-$(uname -r) .config; # current configuration
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 reproduces the bug, so:
git bisect good; # it reproduced the bug!
2. confirm upper bound:
cd linux
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 bug, so:
cd linux
git bisect bad
3. A version half-way between is automatically checked out for
testing. Test:
make deb-pkg; # maybe with -j4
dpkg -i ../<name of package>; # as root
reboot
...test test test ...
Record the result:
cd linux
git bisect good; # if it reproduces the bug
git bisect bad; # if rebooting a few times does not reproduce it
git bisect skip; # if some other bug makes it hard to test
Repeat.
Eventually git tells you the "first bad commit", which is the patch
that alleviated symptoms. If the "gitk" package is installed, you can
see the range of candidates at any step by running "git bisect
visualize". To stop early, run "git bisect log", which produces a log
that others can use to see your results so far or pick up where you
left off. Even a few rounds can narrow down the search by quite a
bit.
You can read more about the "git bisect" tool at
http://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html
but remember, for us a "bad" commit is a commit _not_ exhibiting the
bug and a "good" commit is one that successfully reproduces the bug.
Thanks again for your patience. Hopefully we will have a better idea
of what's going on soon.
Regards,
Jonathan
--
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/20130111021309.gg30...@google.com
