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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/