Hi,
Rares Aioanei wrote:
> Jonathan Nieder <jrnie...@gmail.com> wrote:
>> If I am and the .config indeed seems to be a red herring, would you be
>> willing to bisect between 2.6.38.4 and 2.6.38.5? I can guide you
>> through the process if you'd like (and it probably would have been
>> worth writing a patch for the kernel guide for that by now; sorry).
>
> Yes, I could use some guidance. :-)
Sorry for the long silence. Now the aforementioned patch is at [1]
but I'd rather give more pertinent advice directly.
First I would suggest testing with 2.6.39-1 from experimental. If
that doesn't work, here is how to bisect:
apt-get install build-essential git
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add stable
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.38.y.git
git fetch stable
The above grabs the kernel sources and in addition fetches the 2.6.38.y
series.
git checkout v2.6.38.5
git log v2.6.38.4..v2.6.38.5; # look over the changes
git revert 068e0202; # back out the most relevant-seeming one
make localmodconfig; # minimal configuration
make -j4 deb-pkg
This spends its time building, so go for a hot beverage of your
choice. Then you can test the resulting .deb:
cd ..
dpkg -i linux-image-*.deb
reboot
If it also exhibits the problem, it would be time to test more
systematically. It works like this (git-bisect(1) has details):
cd ~/src/linux-2.6
git bisect start
git bisect bad; # current revision is bad
git bisect bad v2.6.38.5
git bisect good v2.6.38.4
Now it checks out a version halfway between to test:
make silentoldconfig; # reuse configuration
make -j4 deb-pkg
Hopefully this would be faster than the original build. One can
test by installing the resulting package and rebooting. Then
report back:
git bisect good; # if it boots correctly
git bisect bad; # if it exhibits the problem
git bisect skip; # if some other problem makes it hard to test
and it will check out a next version. Since there are 56 patches
between 2.6.38.4 and 2.6.38.5, this would take log(56)/log(2) ~= 6
rounds to pinpoint to an individual patch. The result of testing is
still useful to narrow it down if one gets bored before then. :)
You can get a picture of what's happening at any time with "git bisect
visualize" if the gitk package is installed.
Thanks again, and sorry I don't have any more clever ideas.
Regards,
Jonathan
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=627960
--
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/20110526004142.GB7246@elie
