linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Meduna <stano@meduna.org>
To: Rik van Riel <riel@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Hai Huang <hhuang@redhat.com>
Subject: Re: [PATCH] mm: fix up a spurious page fault whenever it happens
Date: Fri, 24 May 2013 10:29:17 +0200	[thread overview]
Message-ID: <519F24DD.5060700@meduna.org> (raw)
In-Reply-To: <519E095A.4000105@redhat.com>

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?


For the record the cpuinfo for my present testsystem:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 10
model name      : Geode(TM) Integrated Processor by AMD PCS
stepping        : 2
microcode       : 0x88a93d
cpu MHz         : 498.042
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de pse tsc msr cx8 sep pge cmov clflush mmx
                  mmxext 3dnowext 3dnow
bogomips        : 996.08
clflush size    : 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:

and for the Celeron M where I can unfortunately reproduce
it much less often (days to weeks).

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Celeron(R) M processor         1.00GHz
stepping        : 8
cpu MHz         : 1000.011
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
                  mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm
                  pbe nx bts
bogomips        : 2000.02
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:


Thanks
-- 
                                           Stano


  parent reply	other threads:[~2013-05-24  8:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-17  8:42 [PATCH - sort of] x86: Livelock in handle_pte_fault Stanislav Meduna
2013-05-22  0:39 ` Steven Rostedt
2013-05-22  7:32   ` Stanislav Meduna
2013-05-22 12:33   ` Rik van Riel
2013-05-22 15:01     ` Linus Torvalds
2013-05-22 17:41       ` [PATCH] mm: fix up a spurious page fault whenever it happens Rik van Riel
2013-05-22 18:04         ` Stanislav Meduna
2013-05-22 18:11           ` Steven Rostedt
2013-05-22 18:21             ` Stanislav Meduna
2013-05-22 18:35               ` Rik van Riel
2013-05-22 18:42                 ` H. Peter Anvin
2013-05-22 18:43                   ` Rik van Riel
2013-05-23  8:07                     ` Stanislav Meduna
2013-05-23 12:19                       ` Rik van Riel
2013-05-23 13:29                         ` Steven Rostedt
2013-05-23 15:06                           ` H. Peter Anvin
2013-05-23 15:27                             ` Steven Rostedt
2013-05-23 17:24                               ` H. Peter Anvin
2013-05-23 17:36                                 ` Steven Rostedt
2013-05-23 17:38                                   ` H. Peter Anvin
2013-05-24  8:29                         ` Stanislav Meduna [this message]
2013-05-24 10:28                           ` Stanislav Meduna
2013-05-24 13:06                           ` Rik van Riel
2013-05-24 13:55                             ` Stanislav Meduna
2013-05-24 14:23                               ` Stanislav Meduna
2013-06-16 21:34                             ` Stanislav Meduna
2013-06-18 19:13                               ` Stanislav Meduna
2013-06-19  5:20                                 ` Linus Torvalds
2013-06-19  7:36                                   ` Stanislav Meduna
2013-06-19  8:06                                     ` Peter Zijlstra
2013-06-20 17:50                                       ` Stanislav Meduna
2013-05-23 14:45                       ` Linus Torvalds
2013-05-23 14:50                         ` Linus Torvalds
2013-05-23 15:03                           ` Stanislav Meduna
2013-05-22 18:47                 ` Stanislav Meduna

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=519F24DD.5060700@meduna.org \
    --to=stano@meduna.org \
    --cc=hhuang@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=riel@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).