From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755385AbbCSOz3 (ORCPT ); Thu, 19 Mar 2015 10:55:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:49200 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753039AbbCSOz2 (ORCPT ); Thu, 19 Mar 2015 10:55:28 -0400 Date: Thu, 19 Mar 2015 15:55:26 +0100 Message-ID: From: Takashi Iwai To: Denys Vlasenko Cc: Denys Vlasenko , Andy Lutomirski , Jiri Kosina , Linus Torvalds , Stefan Seyfried , X86 ML , LKML , Tejun Heo Subject: Re: PANIC: double fault, error_code: 0x0 in 4.0.0-rc3-2, kvm related? In-Reply-To: References: <5505400B.8050300@message-id.googlemail.com> <5509CBF7.3040602@message-id.googlemail.com> <5509F161.3010101@redhat.com> <550AABCB.9040502@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.4 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Thu, 19 Mar 2015 14:47:12 +0100, Takashi Iwai wrote: > > At Thu, 19 Mar 2015 13:48:56 +0100, > Denys Vlasenko wrote: > > > > Having no more ideas at the moment, here is a tarball of 13 patches > > of commits touching entry_64.S up to 4.0.0-rc1. > > > > x0001.patch is the latest, x0015.patch is the oldest. > > > > Patches 0003 and 0008 are not there since 0003 is empty merge patch > > and 0008 does some PCI fixup. > > > > If this breakage is recent, it ought to be one of these. > > Most of them do some non-trivial surgery. > > > > Even though I did not spot anything suspicious in them, > > entry.S is notorious for subtle breakage. > > > > Try reverting them in sequence starting from x0001.patch > > and see reverting which one makes crash disappear. > > OK, I'm going to check these git series. Reverting the commit 96b6352c12711d5c0bb7157f49c92580248e8146 x86_64, entry: Remove the syscall exit audit and schedule optimizations seems enough. After reverting this one, the machine runs stable with the kvm stress test. (I'll keep test running for a while; at the previous bisection, I hit the bug right after posting the mail ;) BTW, I also tried to reproduce this on another machine (a Haswell laptop), but I failed, even with the very same kernel. So the bug really seems depending on CPU. Takashi