Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759541Ab1EMQNp (ORCPT ); Fri, 13 May 2011 12:13:45 -0400 Received: from mail-pw0-f46.google.com ([209.85.160.46]:36318 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757619Ab1EMQNo convert rfc822-to-8bit (ORCPT ); Fri, 13 May 2011 12:13:44 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rCYkKDTfEqiKDPgXcJ3TeAHMm3eE0w+7h4bUcFZx6C937kqaPHJkg/7ufLloYGy8oi 8xXSSC5DgKDLJ74JW6kIyghSsj2Hzg7/5f9WPEfJ2W2KNyRwSSpbMGR7IbKEFdAynO1g aZp0qZxEqdGbdHdceir9gdvn43eAW1OgjrZnY= MIME-Version: 1.0 In-Reply-To: References: From: Andrew Lutomirski Date: Fri, 13 May 2011 12:13:23 -0400 X-Google-Sender-Auth: lDEBlXagh6MUQKH7Sm4wIpGou1M Message-ID: Subject: Re: AAARGH bisection is hard (Re: [2.6.39 regression] X locks up hard right after logging in) To: Linus Torvalds Cc: Christian Couder , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, git@vger.kernel.org, Shuang He Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2079 Lines: 46 On Fri, May 13, 2011 at 12:11 PM, Linus Torvalds wrote: > On Fri, May 13, 2011 at 7:56 AM, Andrew Lutomirski wrote: >> >> So what I really want is a fancy version of git bisect that makes no >> assumptions about the relationship of good and bad commits in the >> graph and just finds me a commit that is bad but for which all parents >> are good or vice versa. > > Ehh. That's the "non-fancy" way of testing, I'm afraid: if you cannot > make assumption about the relationship between good and bad commits, > then you have to test _every_ commit. > > So yes, bisection has its problems. But they really do come from the > fact that it's very efficient. When you have (on average) about ten > thousand commits between releases, you have to make assumptions about > the relationships. But once you do that, the efficiency also results > in a certain fragility. > > Think of it as a compression method: it generates the smallest > possible set of test points for you. But it's a "lossy" compression - > you don't test everything. And it's extreme: it boils down 10k commit > events to about 13 bisection events. If anything goes wrong (like the > bug not being entirely repeatable, or the bug comes and goes), it will > give the wrong answer. > > The good news is that _usually_ it works really well. And when the > choice is between "works really well for 10k commits but can have > problems" and "you need to test all 10k commits", the "can have > problems" part turns out to be a pretty small downside ;) In conclusion, I found the problem. It's a clusterfuck and I think there's no way that any bisection tool under any sane assumptions could have found it. Patch coming in a couple seconds b/c I think it needs to go in to 2.6.39. --Andy > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?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/