From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 069CFC49ED7 for ; Fri, 13 Sep 2019 17:19:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CDC1E20693 for ; Fri, 13 Sep 2019 17:19:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="gqL0EETY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729657AbfIMRTh (ORCPT ); Fri, 13 Sep 2019 13:19:37 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:44835 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728720AbfIMRTh (ORCPT ); Fri, 13 Sep 2019 13:19:37 -0400 Received: by mail-oi1-f194.google.com with SMTP id w6so3255345oie.11 for ; Fri, 13 Sep 2019 10:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OKzQ7wwphOjxmY/K1EtxnOsTdv2PWzuGJ4C8ws0Egy0=; b=gqL0EETYmHL8v3NKExxXcCfswUCCiPVZzxeoC79eVpYprEt+jozMPa6wAWDltcNb3x VmYaF6bcrZLJnKz9xIIEwoEwF8/jbmki9ju1dVDY7Krqll1tKgk871TOS2FTkEv5VjJL RRtibs3gERfUlHMwswxQ0mabI7O5m4cz9vovI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OKzQ7wwphOjxmY/K1EtxnOsTdv2PWzuGJ4C8ws0Egy0=; b=HJ2w/VYtjLeo880YNu+jAWHAyFzfdbuXPnx02teiQq1nV0f1FmMLdEFg9+N9yJJF0f yeCK8Duo+Fxm2RZWnVvsbxnSm1/H850HpL443xw8vrsqA0mqWZxQ8yZ7I0RoQnQt/F1/ gD2X8/RIel+G40Ng9uZ4oTlmiAkQSk39RqPzKJV462TLgpis/DJwYyZa8amML6KJjT3Z 8l3ttGhMrE6OKrstLdgCQjbN5TDB7AIibAaKRYkiEczpeH84eqpXTEWqeBIHvMy3WZPR PQHR4rrHr6R2UC88RMtGx2Hqbsp2orH5FIC+E8yliz3M1PrjyEBikVSe2OCT9moVGy64 /QrA== X-Gm-Message-State: APjAAAXCcufsTc5/5FKVJ/VHvQP8EFKiGzqmDn4076bfuDwmSnhIfR5q wRWXKeFPk3P4UNx0IT24s7D5wMBmLqsM955Dr6OwKQ== X-Google-Smtp-Source: APXvYqwuw9ZYZrUqJW3S1meWYkCAvipklH3NTP77DVgNvFseKQvu1WlDTpRX3RPGZCmD4dIwv3Hxd1PSyIy8xnCxSnk= X-Received: by 2002:aca:5697:: with SMTP id k145mr4124856oib.101.1568395175833; Fri, 13 Sep 2019 10:19:35 -0700 (PDT) MIME-Version: 1.0 References: <20190907090534.GB1712@pc-sasha.localdomain> <20190908141307.GA7115@pc-sasha.localdomain> <20190909201159.778590a0@canb.auug.org.au> <20190909202128.0c420ddd@canb.auug.org.au> In-Reply-To: From: Daniel Vetter Date: Fri, 13 Sep 2019 19:19:24 +0200 Message-ID: Subject: Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903 To: Alexander Kapshuk Cc: Stephen Rothwell , dri-devel , linux-kernel , Linux-Next , Maarten Lankhorst , Maxime Ripard , Sean Paul , Dave Airlie Content-Type: text/plain; charset="UTF-8" Sender: linux-next-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org On Mon, Sep 9, 2019 at 12:25 PM Alexander Kapshuk wrote: > > On Mon, Sep 9, 2019 at 1:21 PM Stephen Rothwell wrote: > > > > Hi, > > > > On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell wrote: > > > > > > If you are bisecting linux-next, I will suggest bisecting between the > > > stable branch on linux-next (which is just Linus' tree when I started > > > that day) and the top of the first linux-next that fails. (Assuming > > > that the stable branch is good). > > > > Actually (since you won't be bisecting the latest linux-next), you > > probably want to use > > > > git merge-base stable next-20190903 > > (or whatever linux-next you are bisecting) > > > > as your first good commit (assuming it id good :-)). > > > > -- > > Cheers, > > Stephen Rothwell > > Hi Stephen, > > Thanks very much for the tips. > I'll go ahead and give those a try. Yeah this should help, but in general, due to our non-linear history, git bisect can jump around quite a bit. Especially if you only look at dates. Also due to our non-linear history, it sometimes needs to test you a merge-base, to figure out which part of the history it needs to chase for the bad commit. So all normal, but the hint above should help. Also, you don't need to restart git bisect, you can just tell it about any good/bad commit you tested with $ git bisect good|bad $sha1 The more git knows, the quicker it should find the bad commit. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch