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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81CE5C433FE for ; Mon, 18 Oct 2021 02:40:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 66F5D61260 for ; Mon, 18 Oct 2021 02:40:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344960AbhJRCm5 (ORCPT ); Sun, 17 Oct 2021 22:42:57 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:44324 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237610AbhJRCm4 (ORCPT ); Sun, 17 Oct 2021 22:42:56 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 19I2e79V014554; Mon, 18 Oct 2021 04:40:07 +0200 Date: Mon, 18 Oct 2021 04:40:07 +0200 From: Willy Tarreau To: Julia Lawall Cc: Randy Dunlap , linux-kernel@vger.kernel.org, Masahiro Yamada , Michal Marek , linux-kbuild@vger.kernel.org Subject: Re: build reproducibility Message-ID: <20211018024007.GA14455@1wt.eu> References: <7e5485df-a17b-304b-627d-9a85d2464df3@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Julia, On Sun, Oct 17, 2021 at 08:42:31PM +0200, Julia Lawall wrote: > On Sun, 17 Oct 2021, Randy Dunlap wrote: > > My "guess" is that this has something to do with the build > > reusing some current file(s) that need to be rebuilt. > > I.e., adding a "make clean" or "make proper" might be needed. > > This was my guess too. But I have the git clean -dfx. I did a comparison > with make distclean and this does a little more (mostly some files in > tools). Have you tried power-cycling the machine between boots, or just rebooting on a working kernel before booting again on a faulty one ? It could be possible that "something" changes a hardware setting that the BIOS does not touch, leaving your machine in a different state after you've booted the first problematic kernel. For example, it's possible to set some CPU MSRs that affect the maximum CPU power, hence its performance. Normally the BIOS should reset them, but for this it must know about the one your kernel (or even userland) would set. Hoping this helps, Willy