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:

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
+ git bisect good
Bisecting: 30 revisions left to test after this
+ cat .git/HEAD
+ git bisect good
Bisecting: 15 revisions left to test after this
+ cat .git/HEAD
+ git bisect bad
Bisecting: 8 revisions left to test after this
+ cat .git/HEAD
+ git bisect bad
Bisecting: 4 revisions left to test after this
+ cat .git/HEAD
+ git bisect bad
Bisecting: 2 revisions left to test after this
+ cat .git/HEAD
+ git bisect bad
b4634484815e1879512a23e4f59eef648135c30a is first bad commit
diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 
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]>

:040000 040000 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 

The commit changed only sound/pci/bt87x.c

I do believe this line at the end of the bisection:

  b4634484815e1879512a23e4f59eef648135c30a is first bad commit

  diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 

cannot be right.  Where did 3d3c2ae1101c1f2dff7e2f9d514769779dbd2737
come from?  The last good commit was
so shouldn't bisect (if there's really only 1 commit in left now) say

  diff-tree b4634484815e1879512a23e4f59eef648135c30a (from 

  $ git diff 450008b5a62bb09445ae05c4d01d510386c9435d \
              b4634484815e1879512a23e4f59eef648135c30a \
    | grep 'diff --git' | awk '{print $3}'

produces this list of changed files (I'm sure there's an easier way):


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 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
 struct pci_dynid {
        struct list_head node;
        struct pci_device_id id;
  * store_new_id

But whether moving back the CONFIG_HOTPLUG fixes my S3 wake is another
story, one for the acpi-devel list (once I do the experiment).
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

Reply via email to