Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753577Ab3CELbZ (ORCPT ); Tue, 5 Mar 2013 06:31:25 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:51978 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752677Ab3CELbY (ORCPT ); Tue, 5 Mar 2013 06:31:24 -0500 X-Nat-Received: from [202.181.97.72]:63173 [ident-empty] by smtp-proxy.isp with TPROXY id 1362483078.6579 To: fenghua.yu@intel.com, hpa@linux.intel.com Cc: linux-kernel@vger.kernel.org Subject: [3.9-rc1 x86/microcode] Bug in CONFIG_MICROCODE_INTEL_EARLY=y From: Tetsuo Handa References: <201302060035.GCJ00057.FLHMOOFtJFSQOV@I-love.SAKURA.ne.jp> <201303050015.GGI39081.LOVFtOFHQOJFSM@I-love.SAKURA.ne.jp> In-Reply-To: <201303050015.GGI39081.LOVFtOFHQOJFSM@I-love.SAKURA.ne.jp> Message-Id: <201303052031.JFG81705.FSOOFQHJMVFOLt@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Tue, 5 Mar 2013 20:31:17 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 05032013 #9662851, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2099 Lines: 49 Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Hello. > > > > I can boot linux-next-20130205 using kernel config at > > http://I-love.SAKURA.ne.jp/tmp/config-3.8-rc6-next-20130205 . > > But I get VMware's virtual machine kernel stack fault (hardware reset) as soon > > as kernel is loaded if CONFIG_DEBUG_VIRTUAL=y is added to the config above. > > > > Since I don't get kernel stack fault if CONFIG_DEBUG_VIRTUAL=y is added to > > kernel config generated by "make allnoconfig", I guess something is wrong with > > code which is executed at very early stage of bootup. > > > > Any clue? > > > > Regards. > > > > This bug is not yet fixed as of 3.9-rc1. > Should I run git bisect? > > Regards. > I couldn't find the exact commit due to build failure, but I can guess that this problem is triggered by early microcode loading changes, for this problem happens only when CONFIG_MICROCODE_INTEL_EARLY=y on x86_32 kernel. Candidate commits are: 086fc8f8 "x86/tlbflush.h: Define __native_flush_tlb_global_irq_disabled()" e666dfa2 "x86/microcode_intel_lib.c: Early update ucode on Intel's CPU" a8ebf6d1 "x86/microcode_core_early.c: Define interfaces for early loading ucode" ec400dde "x86/microcode_intel_early.c: Early update ucode on Intel's CPU" 63b553c6 "x86/head_32.S: Early update ucode in 32-bit" e6ebf5de "x86/common.c: load ucode in 64 bit or show loading ucode info in 32 bit on AP" d288e1cf "x86/common.c: Make have_cpuid_p() a global function" feddc9de "x86/head64.c: Early update ucode in 64-bit" 9cd4d78e "x86/microcode_intel.h: Define functions and macros for early loading ucode" cd745be8 "x86/mm/init.c: Copy ucode from initrd image to kernel memory" da76f64e "x86/Kconfig: Make early microcode loading a configuration feature" I'm using Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz on VMware Player 4.0.5. Regards. -- 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/