Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760740AbZCPUGe (ORCPT ); Mon, 16 Mar 2009 16:06:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754978AbZCPUGW (ORCPT ); Mon, 16 Mar 2009 16:06:22 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:49288 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754174AbZCPUGV (ORCPT ); Mon, 16 Mar 2009 16:06:21 -0400 Date: Mon, 16 Mar 2009 12:57:18 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Jeff Chua cc: Ingo Molnar , Johannes Berg , "Rafael J. Wysocki" , Linux Kernel Mailing List , Adrian Bunk , Andrew Morton , Kernel Testers List , Network Development , "John W. Linville" Subject: Re: 2.6.29-rc8: Reported regressions from 2.6.28 In-Reply-To: Message-ID: References: <1237140665.24621.2.camel@johannes.local> <1237143683.24621.7.camel@johannes.local> <20090315202603.GA9077@elte.hu> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2167 Lines: 50 On Mon, 16 Mar 2009, Jeff Chua wrote: > > Take the attached bisect log and replay it Taking a bisect log is repeatable, but pointless. If you made any mistakes in bisecting (marking a kernel that was good as being bad, or the other way around), the log will always replay to the same thing, but it will still be wrong. In other words, "git bisect" is only as reliable as the data you feed it, and if the behavior isn't 100% repeatable and unambiguous (or if you simply made a mistake), you need to double-check things. So after bisecting a commit, if there is any question what-so-ever whether the commit makes sense as a result, you need to double-check it. The best way to double-check it is to go back to a known-bad state (preferably the tip of the branch) and revert the presumed-bad commit, and verify that it really fixes the behavior. But if that is impossible (for example, because the commit no longer reverts cleanly), at least make 100% sure that the state at the commit is bad, and then go to (all) parents of that commit and make 100% sure that the state at those points is _good_. IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as being bad, then you should go back and double-check that its parent (in this case 4607816f608b42a5379aca97ceed08378804c99f) is good. Because if it's parent is also bad, then that just means that you made some mistake in "git bisect". The thing about bisecting is that it is _extremely_ efficient. It takes essentially the minimal number of answers to get to the end result. But that very efficiency also means that getting even just _one_ of those answers wrong will take you _way_ off base. There's no room for error, because bisect will take each bit and use it to maximally split the error space. In this case, it really sounds like maybe you marked the parent good, even though you should have marked it bad. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/