1. 11 Mar, 2010 1 commit
    • Paul E. McKenney's avatar
      x86/mce: Fix RCU lockdep splats · f56e8a07
      Paul E. McKenney authored
      Create an rcu_dereference_check_mce() that checks for RCU-sched
      read side and mce_read_mutex being held on update side.  Replace
      uses of rcu_dereference() in arch/x86/kernel/cpu/mcheck/mce.c
      with this new macro.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <1267830207-9474-3-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  2. 08 Dec, 2009 1 commit
  3. 07 Dec, 2009 1 commit
  4. 02 Dec, 2009 1 commit
  5. 26 Nov, 2009 1 commit
  6. 12 Nov, 2009 1 commit
  7. 09 Nov, 2009 1 commit
    • Yong Wang's avatar
      x86: Under BIOS control, restore AP's APIC_LVTTHMR to the BSP value · a2202aa2
      Yong Wang authored
      On platforms where the BIOS handles the thermal monitor interrupt,
      APIC_LVTTHMR on each logical CPU is programmed to generate a SMI
      and OS must not touch it.
      Unfortunately AP bringup sequence using INIT-SIPI-SIPI clears all
      the LVT entries except the mask bit. Essentially this results in
      all LVT entries including the thermal monitoring interrupt set
      to masked (clearing the bios programmed value for APIC_LVTTHMR).
      And this leads to kernel take over the thermal monitoring
      interrupt on AP's but not on BSP (leaving the bios programmed
      value only on BSP).
      As a result of this, we have seen system hangs when the thermal
      monitoring interrupt is generated.
      Fix this by reading the initial value of thermal LVT entry on
      BSP and if bios has taken over the control, then program the
      same value on all AP's and leave the thermal monitoring
      interrupt control on all the logical cpu's to the bios.
      Signed-off-by: default avatarYong Wang <yong.y.wang@intel.com>
      Reviewed-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      LKML-Reference: <20091110013824.GA24940@ywang-moblin2.bj.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: stable@kernel.org
  8. 16 Oct, 2009 3 commits
  9. 13 Oct, 2009 1 commit
    • Hidetoshi Seto's avatar
      perf_event, x86, mce: Use TRACE_EVENT() for MCE logging · 8968f9d3
      Hidetoshi Seto authored
      This approach is the first baby step towards solving many of the
      structural problems the x86 MCE logging code is having today:
       - It has a private ring-buffer implementation that has a number
         of limitations and has been historically fragile and buggy.
       - It is using a quirky /dev/mcelog ioctl driven ABI that is MCE
         specific. /dev/mcelog is not part of any larger logging
         framework and hence has remained on the fringes for many years.
       - The MCE logging code is still very unclean partly due to its ABI
         limitations. Fields are being reused for multiple purposes, and
         the whole message structure is limited and x86 specific to begin
      All in one, the x86 tree would like to move away from this private
      implementation of an event logging facility to a broader framework.
      By using perf events we gain the following advantages:
       - Multiple user-space agents can access MCE events. We can have an
         mcelog daemon running but also a system-wide tracer capturing
         important events in flight-recorder mode.
       - Sampling support: the kernel and the user-space call-chain of MCE
         events can be stored and analyzed as well. This way actual patterns
         of bad behavior can be matched to precisely what kind of activity
         happened in the kernel (and/or in the app) around that moment in
       - Coupling with other hardware and software events: the PMU can track a
         number of other anomalies - monitoring software might chose to
         monitor those plus the MCE events as well - in one coherent stream of
       - Discovery of MCE sources - tracepoints are enumerated and tools can
         act upon the existence (or non-existence) of various channels of MCE
       - Filtering support: we just subscribe to and act upon the events we
         are interested in. Then even on a per event source basis there's
         in-kernel filter expressions available that can restrict the amount
         of data that hits the event channel.
       - Arbitrary deep per cpu buffering of events - we can buffer 32
         entries or we can buffer as much as we want, as long as we have
         the RAM.
       - An NMI-safe ring-buffer implementation - mappable to user-space.
       - Built-in support for timestamping of events, PID markers, CPU
         markers, etc.
       - A rich ABI accessible over system call interface. Per cpu, per task
         and per workload monitoring of MCE events can be done this way. The
         ABI itself has a nice, meaningful structure.
       - Extensible ABI: new fields can be added without breaking tooling.
         New tracepoints can be added as the hardware side evolves. There's
         various parsers that can be used.
       - Lots of scheduling/buffering/batching modes of operandi for MCE
         events. poll() support. mmap() support. read() support. You name it.
       - Rich tooling support: even without any MCE specific extensions added
         the 'perf' tool today offers various views of MCE data: perf report,
         perf stat, perf trace can all be used to view logged MCE events and
         perhaps correlate them to certain user-space usage patterns. But it
         can be used directly as well, for user-space agents and policy action
         in mcelog, etc.
      With this we hope to achieve significant code cleanup and feature
      improvements in the MCE code, and we hope to be able to drop the
      /dev/mcelog facility in the end.
      This patch is just a plain dumb dump of mce_log() records to
      the tracepoints / perf events framework - a first proof of
      concept step.
      Signed-off-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <4AD42A0D.7050104@jp.fujitsu.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  10. 12 Oct, 2009 1 commit
  11. 02 Oct, 2009 1 commit
    • Ingo Molnar's avatar
      x86: EDAC: MCE: Fix MCE decoding callback logic · f436f8bb
      Ingo Molnar authored
      Make decoding of MCEs happen only on AMD hardware by registering a
      non-default callback only on CPU families which support it.
      While looking at the interaction of decode_mce() with the other MCE
      code i also noticed a few other things and made the following
       - Fixed the mce_decode() weak alias - a weak alias is really not
         good here, it should be a proper callback. A weak alias will be
         overriden if a piece of code is built into the kernel - not
         good, obviously.
       - The patch initializes the callback on AMD family 10h and 11h.
       - Added the more correct fallback printk of:
      	No support for human readable MCE decoding on this CPU type.
      	Transcribe the message and run it through 'mcelog --ascii' to decode.
         On CPUs that dont have a decoder.
       - Made the surrounding code more readable.
      Note that the callback allows us to have a default fallback -
      without having to check the CPU versions during the printout
      itself. When an EDAC module registers itself, it can install the
      decode-print function.
      (there's no unregister needed as this is core code.)
      version -v2 by Borislav Petkov:
       - add K8 to the set of supported CPUs
       - always build in edac_mce_amd since we use an early_initcall now
       - fix checkpatch warnings
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      LKML-Reference: <20091001141432.GA11410@aftab>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  12. 30 Sep, 2009 1 commit
  13. 23 Sep, 2009 1 commit
    • Ingo Molnar's avatar
      x86: mce: Use safer ways to access MCE registers · 11868a2d
      Ingo Molnar authored
      Use rdmsrl_safe() when accessing MCE registers. While in
      theory we always 'know' which ones are safe to access from
      the capability bits, there's a lot of hardware variations
      and reality might differ from theory, as it did in this case:
      [    0.010016] mce: CPU supports 5 MCE banks
      [    0.011029] general protection fault: 0000 [#1]
      [    0.011998] last sysfs file:
      [    0.011998] Modules linked in:
      [    0.011998]
      [    0.011998] Pid: 0, comm: swapper Not tainted (2.6.31_router #1) HP Vectra
      [    0.011998] EIP: 0060:[<c100d9b9>] EFLAGS: 00010246 CPU: 0
      [    0.011998] EIP is at mce_rdmsrl+0x19/0x60
      [    0.011998] EAX: 00000000 EBX: 00000001 ECX: 00000407 EDX: 08000000
      [    0.011998] ESI: 00000000 EDI: 8c000000 EBP: 00000405 ESP: c17d5eac
      So WARN_ONCE() instead of crashing the box.
      ( also fix a number of stylistic inconsistencies in the code. )
      Note, we might still crash in wrmsrl() if we get that far, but
      we shouldnt if the registers are truly inaccessible.
      Reported-by: default avatarGNUtoo <GNUtoo@no-log.org>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <bug-14204-5438@http.bugzilla.kernel.org/>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  14. 14 Sep, 2009 2 commits
  15. 26 Aug, 2009 1 commit
    • Hidetoshi Seto's avatar
      x86, mce: CE in last bank prevents panic by unknown MCE · 680b6cfd
      Hidetoshi Seto authored
      If MCE handler is called but none of mces_seen have machine
      check event which might signal the MCE (i.e. event higher than
      MCE_KEEP_SEVERITY), panic with "Machine check from unknown
      source" will be taken since the MCE is assumed to be signaled
      from external agent or so.
      Usually mces_seen never point MCE_KEEP_SEVERITY event such as
      CE. But it can happen because initial value of mces_seen is
      accidentally modified by mce_no_way_out() - in case if
      mce_no_way_out() run through all banks and the last bank has
      the CE, mces_seen points the CE and the "panic by unknown" will
      not be taken.
      This patch fixes this undesired behavior, and clarifies the logic.
      Signed-off-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
      LKML-Reference: <4A94E244.3020301@jp.fujitsu.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Reported-by: default avatarJin Dongming <jin.dongming@np.css.fujitsu.com>
  16. 17 Aug, 2009 2 commits
    • Ingo Molnar's avatar
      x86, mce: Don't initialize MCEs on unknown CPUs · e412cd25
      Ingo Molnar authored
      An older test-box started hanging at the following point during
       [    0.022996] Mount-cache hash table entries: 512
       [    0.024996] Initializing cgroup subsys debug
       [    0.025996] Initializing cgroup subsys cpuacct
       [    0.026995] Initializing cgroup subsys devices
       [    0.027995] Initializing cgroup subsys freezer
       [    0.028995] mce: CPU supports 5 MCE banks
      I've bisected it down to commit 4efc0670
       ("x86, mce: use 64bit
      machine check code on 32bit"), which utilizes the MCE code on
      32-bit systems too.
      The problem is caused by this detail in my config:
        # CONFIG_CPU_SUP_INTEL is not set
      This disables the quirks in mce_cpu_quirks() but still enables
      MCE support - which then hangs due to the missing quirk
      workaround needed on this CPU:
      	if (c->x86 == 6 && c->x86_model < 0x1A && banks > 0)
      		mce_banks[0].init = 0;
      The safe solution is to not initialize MCEs if we dont know on
      what CPU we are running (or if that CPU's support code got
      disabled in the config).
      Also be a bit more defensive on 32-bit systems: dont do a
      boot-time dump of pending MCEs not just on the specific system
      that we found a problem with (Pentium-M), but earlier ones as
      Now this problem is probably not common and disabling CPU
      support is rare - but still being more defensive in something
      we turned on for a wide range of CPUs is prudent.
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      LKML-Reference: Message-ID: <4A88E3E4.40506@jp.fujitsu.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    • Bartlomiej Zolnierkiewicz's avatar
      x86, mce: don't log boot MCEs on Pentium M (model == 13) CPUs · c7f6fa44
      Bartlomiej Zolnierkiewicz authored
      On my legacy Pentium M laptop (Acer Extensa 2900) I get bogus MCE on a cold
      boot with CONFIG_X86_NEW_MCE enabled, i.e. (after decoding it with mcelog):
      MCE 0
      HARDWARE ERROR. This is *NOT* a software problem!
      Please contact your hardware vendor
      CPU 0 BANK 1 MCG status:
      MCi status:
      Error overflow
      Uncorrected error
      Error enabled
      Processor context corrupt
      MCA: Data CACHE Level-1 UNKNOWN Error
      STATUS f200000000000195 MCGSTATUS 0
      [ The other STATUS values observed: f2000000000001b5 (... UNKNOWN error)
        and f200000000000115 (... READ Error).
        To verify that this is not a CONFIG_X86_NEW_MCE bug I also modified
        the CONFIG_X86_OLD_MCE code (which doesn't log any MCEs) to dump
        content of STATUS MSR before it is cleared during initialization. ]
      Since the bogus MCE results in a kernel taint (which in turn disables
      lockdep support) don't log boot MCEs on Pentium M (model == 13) CPUs
      by default ("mce=bootlog" boot parameter can be be used to get the old
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Reviewed-by: default avatarAndi Kleen <andi@firstfloor.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  17. 10 Aug, 2009 2 commits
  18. 29 Jul, 2009 3 commits
  19. 21 Jul, 2009 1 commit
  20. 09 Jul, 2009 4 commits
  21. 08 Jul, 2009 1 commit
  22. 25 Jun, 2009 1 commit
  23. 24 Jun, 2009 1 commit
    • Tejun Heo's avatar
      percpu: clean up percpu variable definitions · 245b2e70
      Tejun Heo authored
      Percpu variable definition is about to be updated such that all percpu
      symbols including the static ones must be unique.  Update percpu
      variable definitions accordingly.
      * as,cfq: rename ioc_count uniquely
      * cpufreq: rename cpu_dbs_info uniquely
      * xen: move nesting_count out of xen_evtchn_do_upcall() and rename it
      * mm: move ratelimits out of balance_dirty_pages_ratelimited_nr() and
        rename it
      * ipv4,6: rename cookie_scratch uniquely
      * x86 perf_counter: rename prev_left to pmc_prev_left, irq_entry to
        pmc_irq_entry and nmi_entry to pmc_nmi_entry
      * perf_counter: rename disable_count to perf_disable_count
      * ftrace: rename test_event_disable to ftrace_test_event_disable
      * kmemleak: rename test_pointer to kmemleak_test_pointer
      * mce: rename next_interval to mce_next_interval
      [ Impact: percpu usage cleanups, no duplicate static percpu var names ]
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: linux-mm <linux-mm@kvack.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
  24. 21 Jun, 2009 1 commit
  25. 18 Jun, 2009 1 commit
  26. 17 Jun, 2009 3 commits
    • Yinghai Lu's avatar
      x86: use zalloc_cpumask_var for mce_dev_initialized · e92fae06
      Yinghai Lu authored
      We need a cleared cpu_mask to record if mce is initialized, especially
      when MAXSMP is used.
      used zalloc_... instead
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Reviewed-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
    • Yinghai Lu's avatar
      x86: fix duplicated sysfs attribute · 74b602c7
      Yinghai Lu authored
      The sysfs attribute cmci_disabled was accidentall turned into a
      duplicate of ignore_ce, breaking all other attributes.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Acked-by: default avatarHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
    • Andi Kleen's avatar
      x86: mce: Handle banks == 0 case in K7 quirk · 203abd67
      Andi Kleen authored
      Vegard Nossum reported:
      > I get an MCE-related crash like this in latest linus tree:
      > [    0.115341] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
      > [    0.116396] CPU: L2 Cache: 512K (64 bytes/line)
      > [    0.120570] mce: CPU supports 0 MCE banks
      > [    0.124870] BUG: unable to handle kernel NULL pointer dereference at 00000000 00000010
      > [    0.128001] IP: [<ffffffff813b98ad>] mcheck_init+0x278/0x320
      > [    0.128001] PGD 0
      > [    0.128001] Thread overran stack, or stack corrupted
      > [    0.128001] Oops: 0002 [#1] PREEMPT SMP
      > [    0.128001] last sysfs file:
      > [    0.128001] CPU 0
      > [    0.128001] Modules linked in:
      > [    0.128001] Pid: 0, comm: swapper Not tainted 2.6.30 #426
      > [    0.128001] RIP: 0010:[<ffffffff813b98ad>]  [<ffffffff813b98ad>] mcheck_init+0x278/0x320
      > [    0.128001] RSP: 0018:ffffffff81595e38  EFLAGS: 00000246
      > [    0.128001] RAX: 0000000000000010 RBX: ffffffff8158f900 RCX: 0000000000000000
      > [    0.128001] RDX: 0000000000000000 RSI: 00000000000000ff RDI: 0000000000000010
      > [    0.128001] RBP: ffffffff81595e68 R08: 0000000000000001 R09: 0000000000000000
      > [    0.128001] R10: 0000000000000010 R11: 0000000000000000 R12: 0000000000000000
      > [    0.128001] R13: 00000000ffffffff R14: 0000000000000000 R15: 0000000000000000
      > [    0.128001] FS:  0000000000000000(0000) GS:ffff880002288000(0000) knlGS:00000
      > 00000000000
      > [    0.128001] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      > [    0.128001] CR2: 0000000000000010 CR3: 0000000001001000 CR4: 00000000000006b0
      > [    0.128001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [    0.128001] DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
      > [    0.128001] Process swapper (pid: 0, threadinfo ffffffff81594000, task ffffff
      > ff8152a4a0)
      > [    0.128001] Stack:
      > [    0.128001]  0000000081595e68 5aa50ed3b4ddbe6e ffffffff8158f900 ffffffff8158f
      > 914
      > [    0.128001]  ffffffff8158f948 0000000000000000 ffffffff81595eb8 ffffffff813b8
      > 69c
      > [    0.128001]  5aa50ed3b4ddbe6e 00000001078bfbfd 0000062300000800 5aa50ed3b4ddb
      > e6e
      > [    0.128001] Call Trace:
      > [    0.128001]  [<ffffffff813b869c>] identify_cpu+0x331/0x392
      > [    0.128001]  [<ffffffff815a1445>] identify_boot_cpu+0x23/0x6e
      > [    0.128001]  [<ffffffff815a14ac>] check_bugs+0x1c/0x60
      > [    0.128001]  [<ffffffff8159c075>] start_kernel+0x403/0x46e
      > [    0.128001]  [<ffffffff8159b2ac>] x86_64_start_reservations+0xac/0xd5
      > [    0.128001]  [<ffffffff8159b3ea>] x86_64_start_kernel+0x115/0x14b
      > [    0.128001]  [<ffffffff8159b140>] ? early_idt_handler+0x0/0x71
      This happens on QEMU which reports MCA capability, but no banks.
      Without this patch there is a buffer overrun and boot ops because
      the code would try to initialize the 0 element of a zero length
      kmalloc() buffer.
      Reported-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Tested-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      LKML-Reference: <20090615125200.GD31969@one.firstfloor.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  27. 16 Jun, 2009 2 commits