rc6-git8 Makefile from cg-export and bz2 patch don't agree
I wanted to get a clean 2.6.12-rc6-git8 tree, so I looked up the commit id (3edea4833a1efcd43e1dff082bc8001fdfe74b34) at http://kernel.org/pub/linux/kernel/v2.6/snapshots/, updated my .git repository with rsync -a --delete --verbose --stats --progress \ rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \ .git/ then did cg-export /tmp/xyz commit-id Strangely, the Makefile doesn't match what I would get by applying patch-2.6.13-rc6-git8.bz2. In the exported Makefile, EXTRAVERSION =-rc6 whereas from the patch, Makefile (line 151 of the diff) has EXTRAVERSION = -rc6-git8 Was this a case of hand-editing the diff or did I not use the cg/git commands correctly? -Sanjoy `A society of sheep must in time beget a government of wolves.' - Bertrand de Jouvenal - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisect gives strange answer
If you see any sort of evidence that this would hold true I really like to know. I haven't found any evidence. When I rebuilt the kernels from scratch (exporting them into an empty directory using cg-export), I got reliable data and bisected down to a patch that probably was a problem. I will redo those tests but rebuilding in place after each bisection (with -f added to all the git checkout uses in git-bisect-script) and see whether I get the same results. If I don't, it could be due to git or git-bisect (but not so likely with the -f switch) or to the build system. Will keep you and Junio posted. -Sanjoy - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisect gives strange answer
By any chance, is this patch causing you problems?
No, sadly. But I had hopes! As I think about it more, there's no way
it could, since I have CONFIG_HOTPLUG=y, so moving the CONFIG_HOTPLUG
would not change anything (for those who don't know the patch, it is
appended below).
My latest theory is that I fed bisect incorrect good/bad data.
Perhaps If I had checked out and compiled those intermediate versions
from scratch, each version in a separate directory, then I would have
got different answers. Two possible reasons:
1. The kernel Makefiles ar do not understand every subtle dependency.
So they might get confused by updating to different tree states (as
the bisect progresses) because those updates change Makefiles and
include files. In other words, I should have done 'make clean' or
'make mrproper' before each kernel compile.
2. git-bisect-script doesn't use -f when it does 'git checkout', so
files that should be updated are not. Right now I'm in the middle
of recollecting the data with git-bisect-script using -f in all
uses of git checkout (unless that is a really silly idea).
-Sanjoy
git diff a18bcb7450840f07a772..3d3c2ae1101c1f2dff7e2f9d514769779dbd2737
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -17,13 +17,13 @@
* Dynamic device IDs are disabled for !CONFIG_HOTPLUG
*/
-#ifdef CONFIG_HOTPLUG
-
struct pci_dynid {
struct list_head node;
struct pci_device_id id;
};
+#ifdef CONFIG_HOTPLUG
+
/**
* store_new_id
*
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisect gives strange answer
Em, if you don't compile/test those intermediate versions, how do you know whether to tag it good/bad ? Sorry, I wrote this part carelessly: If I had checked out and compiled those intermediate versions from scratch... I meant to emphasize the 'from scratch'. I did check out and compile the versions, but I didn't compile from scratch. i.e. I just took whatever directory tree I got after git bisect good or git bisect bad and then did 'make -j 4'. Perhaps I should have done make clean restore .config make -j 4 to be really sure that every file that needed recompilation got recompiled. -Sanjoy - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bisect gives strange answer
I have been having lots of fun using 'git bisect' to find the commit
that broke S3 wake on my laptop. But in its last step it gives an
answer that cannot be right. I had not used git until now, so I may be
missing something obvious: Corrections will be gratefully received. I'm
using git from git-2005-08-03.tar.gz on i386 (TP 600X, Debian testing).
Before using git bisect, I had tested enough to know that 2.6.13-rc1 was
fine and 2.6.13-rc2-git1 was not (it would sleep but waking up would
hang). So I compiled all the 2.6.13-rc1-git* snapshots and found that
2.6.13-rc1-git7 was the last one that worked, and 2.6.13-rc2-git1 was
the first to fail (see http://bugzilla.kernel.org/show_bug.cgi?id=4989
if you are curious about the bug itself).
Time to use 'git bisect' to find where in between the S3 wake got
broken. I'll give all the commands I did so you can (hopefully!)
reproduce the problem.
I began by following the useful directions at
http://linux.yyz.us/git-howto.html to download the 2.6 repository:
repo=rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git clone $repo linux-2.6
cd linux-2.6
rsync -a --verbose --stats --progress $repo/ .git/
Then I binary searched, compiling and testing, until bisect told me I
was done. Here's the output of a script (run with #!/bin/bash -x) that
reproduces the problem in the clean archive made above.
==
+ git checkout
+ git bisect reset
+ git bisect start
+ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3 # 2.6.13-rc1-git7
+ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6 # 2.6.13-rc2-git1
Bisecting: 42 revisions left to test after this
+ cat .git/HEAD
b2f571026594884e7a2a3f8bc6ad5c92e0703330
+ git bisect good
Bisecting: 30 revisions left to test after this
+ cat .git/HEAD
450008b5a62bb09445ae05c4d01d510386c9435d
+ git bisect good
Bisecting: 15 revisions left to test after this
+ cat .git/HEAD
a9df3597fec5472d0840fbfdc2a3fac5268f7d08
+ git bisect bad
Bisecting: 8 revisions left to test after this
+ cat .git/HEAD
28e8c3ad9464de54a632f00ab3df88fa5f4652d1
+ git bisect bad
Bisecting: 4 revisions left to test after this
+ cat .git/HEAD
c774e93e2152d0be2612739418689e6e6400f4eb
+ git bisect bad
Bisecting: 2 revisions left to test after this
+ cat .git/HEAD
b4634484815e1879512a23e4f59eef648135c30a
+ git bisect bad
b4634484815e1879512a23e4f59eef648135c30a is first bad commit
diff-tree b4634484815e1879512a23e4f59eef648135c30a (from
3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)
Author: Greg KH [EMAIL PROTECTED]
Date: Wed Jul 6 08:51:03 2005 -0700
[PATCH] Fix bt87x.c build problem
Missing forward declaration
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
:04 04 5717e17e384b0b40e409966403e2b8dfdab615a9
4ba0c028e80bf81c5c782e9047bd484a1eeadca4 M sound
==
The answer makes no sense since my .config doesn't use the bt87x driver
(the TP600X uses a snd-cs46xx). To be sure, I checked the diff with
git diff
3d3c2ae1101c1f2dff7e2f9d514769779dbd2737..b4634484815e1879512a23e4f59eef648135c30a
The commit changed only sound/pci/bt87x.c
I do believe this line at the end of the bisection:
b4634484815e1879512a23e4f59eef648135c30a is first bad commit
But
diff-tree b4634484815e1879512a23e4f59eef648135c30a (from
3d3c2ae1101c1f2dff7e2f9d514769779dbd2737)
cannot be right. Where did 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737
come from? The last good commit was
450008b5a62bb09445ae05c4d01d510386c9435d
so shouldn't bisect (if there's really only 1 commit in left now) say
diff-tree b4634484815e1879512a23e4f59eef648135c30a (from
450008b5a62bb09445ae05c4d01d510386c9435d)
$ git diff 450008b5a62bb09445ae05c4d01d510386c9435d \
b4634484815e1879512a23e4f59eef648135c30a \
| grep 'diff --git' | awk '{print $3}'
produces this list of changed files (I'm sure there's an easier way):
a/arch/arm/kernel/armksyms.c
a/arch/arm/mach-ixp4xx/common-pci.c
a/arch/arm/mach-ixp4xx/coyote-setup.c
a/arch/arm/mach-ixp4xx/ixdp425-setup.c
a/arch/arm/mm/proc-v6.S
a/drivers/pci/pci-driver.c
a/include/asm-arm/arch-ixp4xx/io.h
a/sound/pci/bt87x.c
I suspect that bisect jumped the gun at the end, and that there are a
few more revisions to test. Maybe the revision tree structure gets a
bit complicated and breaks an implicit linearity assumption in bisect?
Probably 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737 is the commit just
before b4634484815e1879512a23e4f59eef648135c30a (the first one I know to
be bad), and I'm guessing that 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737
is bad too.
The suspect change is probably to drivers/pci/pci-driver.c since all the
other changed files are the unused bt87x sound driver or are for the arm
architecture. Here is that diff:
diff --git a/drivers/pci/pci-driver.c
