Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755315Ab3EXNHU (ORCPT ); Fri, 24 May 2013 09:07:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10104 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753187Ab3EXNHS (ORCPT ); Fri, 24 May 2013 09:07:18 -0400 Message-ID: <519F65DB.2020305@redhat.com> Date: Fri, 24 May 2013 09:06:35 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stanislav Meduna CC: "H. Peter Anvin" , Steven Rostedt , Linus Torvalds , "linux-rt-users@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , the arch/x86 maintainers , Hai Huang Subject: Re: [PATCH] mm: fix up a spurious page fault whenever it happens References: <5195ED8B.7060002@meduna.org> <1369183168.6828.168.camel@gandalf.local.home> <519CBB30.3060200@redhat.com> <20130522134111.33a695c5@cuia.bos.redhat.com> <519D08B0.8050707@meduna.org> <1369246316.6828.176.camel@gandalf.local.home> <519D0CAB.7020800@meduna.org> <519D0FF8.5080200@redhat.com> <519D118B.6010306@zytor.com> <519D11BF.5000604@redhat.com> <519DCE2A.4010801@meduna.org> <519E095A.4000105@redhat.com> <519F24DD.5060700@meduna.org> In-Reply-To: <519F24DD.5060700@meduna.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1199 Lines: 35 On 05/24/2013 04:29 AM, Stanislav Meduna wrote: > On 23.05.2013 14:19, Rik van Riel wrote: > >>>> static inline void __native_flush_tlb_single(unsigned long addr) >>>> { >>>> __flush_tlb(); >>>> } >> >>> I will give it some more testing time. >> >> That is a good idea. > > Still no crash, so this one indeed seems to change things. > > If I understand it correctly, these patches fix the problem > when it happens and we still don't know why the TLB is stale > in the first place - whether there is (also) a genuine bug > or whether we are hitting some chip errata, right? Just to rule something out, are you using transparent huge pages on those systems? That could result in a mix of 4MB and 4kB mappings, sometimes of the same memory. The page tables would only ever contain one of those mappings, but if we have some kind of TLB problem, we might preserve a large mapping across a page breakup, or a small one across a page collapse... -- 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/