Received: by 10.192.165.156 with SMTP id m28csp1258385imm; Wed, 18 Apr 2018 06:55:03 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/jpVz6OiwYMIc8hMNzu9iYhfBY1l5VKx5o0DvELDfzG+AjJuszd4WLscohhkJHRZx4xg1q X-Received: by 2002:a17:902:b595:: with SMTP id a21-v6mr2211132pls.68.1524059703112; Wed, 18 Apr 2018 06:55:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524059703; cv=none; d=google.com; s=arc-20160816; b=rtIjwHtAHLwZreJ2b1DMtHmnIYFv9kxWmwhWfjkBZQF90SN52/p2T+y55ThtT6oVdy jMyMpWKsAQZQNalm4K5KIOhOAEhkZI3hWDw+DFl/bl0FgFQ7W8vI0ZrCmVCjTLR0Yyz8 WmTXOlAzkmotgOQp6Yjcgw5UoAP3M1DCmxF2zxmZhT222ohmpVAhpCknVy8iP10hhqDD TFbZtgZK4AI2IridOFvbzlwCgj3IoNVw0dKqfVFSOiNLejdHSD5N2hqu2pIUoIjmWpAm EYUMVOjY3/PUCNWu/Mu31panv422uGnPpsznc6Q4zIoP+sP0SYmzhPT0oZgaVFUaNsvE Cpog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=g25rPSv8JgF9NCkWA3pDlDYQaX316sZzOl4jlmOSfLg=; b=spvx6AB+bWWEQiHeLiunRisMvylLALzy+WHqDYYZyRMvTYukNt4XgLmeaURtQdePey KI542iw0KTTY2AxKffXhVU3hqqsGv4K+mDG6g+gHCxNxytzkr880Fb0ZxT26D+MYRBF0 49oWassOy4Mm5lZMtYBsJJAEhp9knwF6r5qxpwRPG4Cx5oYXi15AGJ8+hzV10TntQrZ+ 4V2kUHpB2S2lBAUkuhPk1Plk6N5556btE5gt/UpbBZPUG20CA1a47MV9mOeRdzamx3Gw PFplKiDyntKzLViQUd5dVrNOcIXjsBDxWclcbluPvknJRCKRUv2q1QQQ/iW4cFuLwwNy hreQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s16-v6si1234961plp.487.2018.04.18.06.54.48; Wed, 18 Apr 2018 06:55:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752965AbeDRNxd (ORCPT + 99 others); Wed, 18 Apr 2018 09:53:33 -0400 Received: from mga05.intel.com ([192.55.52.43]:39449 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752087AbeDRNxc (ORCPT ); Wed, 18 Apr 2018 09:53:32 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2018 06:53:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,465,1517904000"; d="scan'208";a="221415504" Received: from araj-mobl1.jf.intel.com ([10.254.11.127]) by fmsmga006.fm.intel.com with ESMTP; 18 Apr 2018 06:53:31 -0700 Date: Wed, 18 Apr 2018 06:53:30 -0700 From: "Raj, Ashok" To: Borislav Petkov Cc: Vitezslav Samel , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Ashok Raj Subject: Re: 4.15.17 regression: bisected: timeout during microcode update Message-ID: <20180418135330.GA23580@araj-mobl1.jf.intel.com> References: <20180418081140.GA2439@pc11.op.pod.cz> <20180418100721.GA5866@pd.tnic> <20180418120839.GA5655@pc11.op.pod.cz> <20180418122212.GA4290@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180418122212.GA4290@pd.tnic> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 18, 2018 at 02:22:12PM +0200, Borislav Petkov wrote: > On Wed, Apr 18, 2018 at 02:08:40PM +0200, Vitezslav Samel wrote: > > I switched to firmware-in-kernel early loading and that works OK. firmware-in-kernel means you compile your microcode image in linux? Can you tell me which distro you are using? The ones we used doesn't do late-loading (i.e echo 1 > /sys/devices/system/cpu/microcode/reload) I suspect that might be the problem. - Can you remove your builtin microcode, - rename the /lib/firmware/intel-ucode so we don't find it during late loading. - let the system boot completely - then rename the intel-ucode back for this test. - write 1 to reload and see if that update succeeds or fails? > > Ok, and keep using that from now on. > > People should all move away from that late loading dance. I'm saying > that in case someone else reads this on lkml. > > > But still, the reported issue is regression in 4.15.17 and 4.16+. > > Oh, I know it is a regression. > > @Ashok: anything particular about his microcode revision not being able > to stomach late loading? nothing about the microcode itself comes to mind. I'm wondering if this similar to the Arch linux that used late-load during booting might be an issue.