Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750917AbdL2X4f (ORCPT ); Fri, 29 Dec 2017 18:56:35 -0500 Received: from mail-it0-f45.google.com ([209.85.214.45]:34437 "EHLO mail-it0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750709AbdL2X4d (ORCPT ); Fri, 29 Dec 2017 18:56:33 -0500 X-Google-Smtp-Source: ACJfBosqgMVjUEhbDv0l+jV075K1OxiVKnjWm6bu5p8uLwowciNlp1JhL1Eo/wMzB8qXC2eO+nWs8JESr6nhe2VpGAo= MIME-Version: 1.0 In-Reply-To: <1514589329.28262.20.camel@tsoy.me> References: <1514453602.6251.8.camel@tsoy.me> <20171229091741.GC18441@kroah.com> <1514557888.28262.1.camel@tsoy.me> <1514558513.28262.3.camel@tsoy.me> <1b4569ee-8c06-4480-447b-2af8f6804053@intel.com> <1514578936.28262.11.camel@tsoy.me> <1514584257.28262.13.camel@tsoy.me> <1514589329.28262.20.camel@tsoy.me> From: Linus Torvalds Date: Fri, 29 Dec 2017 15:56:32 -0800 X-Google-Sender-Auth: IMnoGNL9wXOnj4fSjdIHshov7FE Message-ID: Subject: Re: 4.14.9 with CONFIG_MCORE2 fails to boot To: Alexander Tsoy , =?UTF-8?Q?Toralf_F=C3=B6rster?= Cc: Dave Hansen , Greg KH , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Boris Ostrovsky , Borislav Petkov , Borislav Petkov , Brian Gerst , Dave Hansen , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , "H. Peter Anvin" , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Rik van Riel , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Kernel Mailing List , stable Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id vBTNudqT032434 Content-Length: 928 Lines: 28 On Fri, Dec 29, 2017 at 3:15 PM, Alexander Tsoy wrote: > В Пт, 29/12/2017 в 14:09 -0800, Linus Torvalds пишет: >> >> What happens if you take a failing kernel, and then in >> arch/x86/kernel/traps.c do_double_fault(), you change the >> >> #ifdef CONFIG_X86_ESPFIX64 >> >> to just a >> >> #if 0 >> >> do you then get an actual double-fault oops report instead of the >> stall (and NMI oops)? > > This is what I get after disabling ESPFIX64 (see attachment). Ok, looks like it made no difference for you or for Toralf. So that was a waste of time. Damn. Also very strange how there's that double fault in the call trace, but no actual output from any double fault. Without the ESPFIX64 code, I don't see how that happens, but since I have no idea what is going on here, I'm obviously missing a lot. Hopefully somebody else has a clue or sees something I'm missing. Linus