Mirek Jezbera wrote:
> On Po 20.úno, Jonathan Nieder wrote:
>> Mirek Jezbera wrote:
>>> I have recompiled kernel 3.2.6 (from unstable kernel sources 3.2.6-1) to
>>> have
>>> same options as working 3.3.0-rc1 kernel. From 5 boots I have gui three
>>> times
>>> and black screen twice.
>>> With linux kernel 3.3.0-rc1 I have always booted into gui.
[...]
> It seems, that there is some race condition issue in kernel.
Yeah.
A lot happened between v3.2 and v3.3-rc1, unfortunately. Would you be
able to bisect to narrow down the search for the fix?
It works like this:
0. Prerequisites:
apt-get install git build-essential
1. Get the kernel, if you don't already have it.
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
2. Try v3.2. Hopefully it does not contain the fix.
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>
reboot until the gdm flicker happens (giving up after a few
times if it doesn't happen)
git checkout v3.3-rc1
git bisect start -- drivers/gpu/drm
git bisect good v3.2; # reproduces the bug
3. If that reproduced the bug, try v3.3-rc1.
make silentoldconfig; # reuse configuration
make deb-pkg; # maybe with -j4
dpkg -i ../<name of package>
reboot until the gdm flicker happens (giving up after 10 or so
trials if it doesn't happen, which we would hope)
git bisect good; # if gdm flickers
git bisect bad; # if you cannot get it to flicker
git bisect skip; # if some other bug makes it hard to test
Hopefully it does contain the fix, so you can run "git bisect bad".
4. Git checks out a version half-way between to test; repeat
until it finds the "first bad commit", which will be the fix.
If the gitk package is installed, you can run "git bisect
visualize" to watch the search space for the fix narrowing.
If you get bored before it finishes, the partial result shown
by "git bisect log" will already be useful.
To recap: a few rounds of bisecting would be very useful. It is
fussy because the bug is not 100% reproducible and a little
counterintuitive because since we are searching for the patch that
introduced a fix rather than a bug, our values are backwards:
good = buggy
bad = fixed
Hope that helps,
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/20120302183339.GF20520@burratino
