1. 08 3月, 2010 1 次提交
  2. 20 9月, 2009 1 次提交
  3. 04 9月, 2009 1 次提交
  4. 24 6月, 2009 1 次提交
    • T
      percpu: cleanup percpu array definitions · 204fba4a
      Tejun Heo 提交于
      Currently, the following three different ways to define percpu arrays
      are in use.
      
      1. DEFINE_PER_CPU(elem_type[array_len], array_name);
      2. DEFINE_PER_CPU(elem_type, array_name[array_len]);
      3. DEFINE_PER_CPU(elem_type, array_name)[array_len];
      
      Unify to #1 which correctly separates the roles of the two parameters
      and thus allows more flexibility in the way percpu variables are
      defined.
      
      [ Impact: cleanup ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: linux-mm@kvack.org
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: David S. Miller <davem@davemloft.net>
      204fba4a
  5. 17 6月, 2009 1 次提交
  6. 29 5月, 2009 4 次提交
  7. 18 3月, 2009 1 次提交
  8. 13 3月, 2009 1 次提交
  9. 25 2月, 2009 2 次提交
  10. 21 2月, 2009 1 次提交
    • H
      x86, mce: remove incorrect __cpuinit for mce_cpu_features() · cc3ca220
      H. Peter Anvin 提交于
      Impact: Bug fix on UP
      
      Checkin 6ec68bff:
          x86, mce: reinitialize per cpu features on resume
      
      introduced a call to mce_cpu_features() in the resume path, in order
      for the MCE machinery to get properly reinitialized after a resume.
      However, this function (and its successors) was flagged __cpuinit,
      which becomes __init on UP configurations (on SMP suspend/resume
      requires CPU hotplug and so this would not be seen.)
      
      Remove the offending __cpuinit annotations for mce_cpu_features() and
      its successor functions.
      
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      cc3ca220
  11. 20 2月, 2009 2 次提交
    • A
      x86, mce: separate correct machine check poller and fatal exception handler · b79109c3
      Andi Kleen 提交于
      Impact: cleanup, performance enhancement
      
      The machine check poller is diverging more and more from the fatal
      exception handler. Instead of adding more special cases separate the code
      paths completely. The corrected poll path is actually quite simple,
      and this doesn't result in much code duplication.
      
      This makes both handlers much easier to read and results in
      cleaner code flow.  The exception handler now only needs to care
      about uncorrected errors, which also simplifies the handling of multiple
      errors. The corrected poller also now always runs in standard interrupt
      context and does not need to do anything special to handle NMI context.
      
      Minor behaviour changes:
      - MCG status is now not cleared on polling.
      - Only the banks which had corrected errors get cleared on polling
      - The exception handler only clears banks with errors now
      
      v2: Forward port to new patch order. Add "uc" argument.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      b79109c3
    • A
      x86, mce: factor out duplicated struct mce setup into one function · b5f2fa4e
      Andi Kleen 提交于
      Impact: cleanup
      
      This merely factors out duplicated code to set up
      the initial struct mce state into a single function.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      b5f2fa4e
  12. 18 2月, 2009 1 次提交
  13. 17 2月, 2009 1 次提交
  14. 12 1月, 2009 1 次提交
  15. 07 1月, 2009 1 次提交
    • L
      x86: fix section mismatch warnings in mcheck/mce_amd_64.c · 51d7a139
      Leonardo Potenza 提交于
      Mark the function local_allocate_threshold_blocks() with __cpuinit,
      in order to remove the following section mismatch messages:
      
      WARNING: arch/x86/kernel/cpu/mcheck/built-in.o(.text+0x1363): Section mismatch in reference from the function local_allocate_threshold_blocks() to the function .cpuinit.text:allocate_threshold_blocks()
      The function local_allocate_threshold_blocks() references
      the function __cpuinit allocate_threshold_blocks().
      This is often because local_allocate_threshold_blocks lacks a __cpuinit
      annotation or the annotation of allocate_threshold_blocks is wrong.
      
      WARNING: arch/x86/kernel/cpu/built-in.o(.text+0x1def): Section mismatch in reference from the function local_allocate_threshold_blocks() to the function .cpuinit.text:allocate_threshold_blocks()
      The function local_allocate_threshold_blocks() references
      the function __cpuinit allocate_threshold_blocks().
      This is often because local_allocate_threshold_blocks lacks a __cpuinit
      annotation or the annotation of allocate_threshold_blocks is wrong.
      
      WARNING: arch/x86/kernel/built-in.o(.text+0xef2b): Section mismatch in reference from the function local_allocate_threshold_blocks() to the function .cpuinit.text:allocate_threshold_blocks()
      The function local_allocate_threshold_blocks() references
      the function __cpuinit allocate_threshold_blocks().
      This is often because local_allocate_threshold_blocks lacks a __cpuinit
      annotation or the annotation of allocate_threshold_blocks is wrong.
      
      All the callsites of this function are __cpuinit already, and all the
      functions it calls are __cpuinit as well.
      Signed-off-by: NLeonardo Potenza <lpotenza@inwind.it>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      51d7a139
  16. 17 12月, 2008 2 次提交
  17. 23 8月, 2008 1 次提交
    • R
      x86 MCE: Fix CPU hotplug problem with multiple multicore AMD CPUs · 8735728e
      Rafael J. Wysocki 提交于
      During CPU hot-remove the sysfs directory created by
      threshold_create_bank(), defined in
      arch/x86/kernel/cpu/mcheck/mce_amd_64.c, has to be removed before
      its parent directory, created by mce_create_device(), defined in
      arch/x86/kernel/cpu/mcheck/mce_64.c .  Moreover, when the CPU in
      question is hotplugged again, obviously the latter has to be created
      before the former.  At present, the right ordering is not enforced,
      because all of these operations are carried out by CPU hotplug
      notifiers which are not appropriately ordered with respect to each
      other.  This leads to serious problems on systems with two or more
      multicore AMD CPUs, among other things during suspend and hibernation.
      
      Fix the problem by placing threshold bank CPU hotplug callbacks in
      mce_cpu_callback(), so that they are invoked at the right places,
      if defined.  Additionally, use kobject_del() to remove the sysfs
      directory associated with the kobject created by
      kobject_create_and_add() in threshold_create_bank(), to prevent the
      kernel from crashing during CPU hotplug operations on systems with
      two or more multicore AMD CPUs.
      
      This patch fixes bug #11337.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NAndi Kleen <andi@firstfloor.org>
      Tested-by: NMark Langsdorf <mark.langsdorf@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8735728e
  18. 24 5月, 2008 1 次提交
  19. 20 4月, 2008 1 次提交
  20. 30 1月, 2008 4 次提交
  21. 28 1月, 2008 1 次提交
    • G
      x86: fix runtime error in arch/x86/kernel/cpu/mcheck/mce_amd_64.c · 404aae5d
      Greg Kroah-Hartman 提交于
      This problem is due to the kobject rework recently done in this file.
      
      The mce_amd_64.c code uses some wierd forward calls to back out of the
      recursive way the code creates kobjects.  Because of this, we need to
      verify that we have really created a kobject before calling
      kobject_uevent().
      
      Many thanks to Yinghai Lu <yhlu.kernel@gmail.com> for reporting the
      problem and testing.
      
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: Jacob Shin <jacob.shin@amd.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      404aae5d
  22. 25 1月, 2008 3 次提交
  23. 24 10月, 2007 1 次提交
  24. 20 10月, 2007 1 次提交
    • M
      x86: convert cpuinfo_x86 array to a per_cpu array · 92cb7612
      Mike Travis 提交于
      cpu_data is currently an array defined using NR_CPUS.  This means that
      we overallocate since we will rarely really use maximum configured cpus.
      When NR_CPU count is raised to 4096 the size of cpu_data becomes
      3,145,728 bytes.
      
      These changes were adopted from the sparc64 (and ia64) code.  An
      additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
      index.  This corresponds to the index into a cpumask_t as well as the
      per_cpu index.  It's used in various places like show_cpuinfo().
      
      cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
      case.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Mark M. Hoffman <mhoffman@lightlink.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      92cb7612
  25. 18 10月, 2007 1 次提交
    • J
      x86: expand /proc/interrupts to include missing vectors, v2 · 38e760a1
      Joe Korty 提交于
      Add missing IRQs and IRQ descriptions to /proc/interrupts.
      
      /proc/interrupts is most useful when it displays every IRQ vector in use by
      the system, not just those somebody thought would be interesting.
      
      This patch inserts the following vector displays to the i386 and x86_64
      platforms, as appropriate:
      
      	rescheduling interrupts
      	TLB flush interrupts
      	function call interrupts
      	thermal event interrupts
      	threshold interrupts
      	spurious interrupts
      
      A threshold interrupt occurs when ECC memory correction is occuring at too
      high a frequency.  Thresholds are used by the ECC hardware as occasional
      ECC failures are part of normal operation, but long sequences of ECC
      failures usually indicate a memory chip that is about to fail.
      
      Thermal event interrupts occur when a temperature threshold has been
      exceeded for some CPU chip.  IIRC, a thermal interrupt is also generated
      when the temperature drops back to a normal level.
      
      A spurious interrupt is an interrupt that was raised then lowered by the
      device before it could be fully processed by the APIC.  Hence the apic sees
      the interrupt but does not know what device it came from.  For this case
      the APIC hardware will assume a vector of 0xff.
      
      Rescheduling, call, and TLB flush interrupts are sent from one CPU to
      another per the needs of the OS.  Typically, their statistics would be used
      to discover if an interrupt flood of the given type has been occuring.
      
      AK: merged v2 and v4 which had some more tweaks
      AK: replace Local interrupts with Local timer interrupts
      AK: Fixed description of interrupt types.
      
      [ tglx: arch/x86 adaptation ]
      [ mingo: small cleanup ]
      Signed-off-by: NJoe Korty <joe.korty@ccur.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Tim Hockin <thockin@hockin.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      38e760a1
  26. 17 10月, 2007 1 次提交
    • M
      x86: Convert cpu_core_map to be a per cpu variable · 08357611
      Mike Travis 提交于
      This is from an earlier message from 'Christoph Lameter':
      
          cpu_core_map is currently an array defined using NR_CPUS. This means that
          we overallocate since we will rarely really use maximum configured cpu.
      
          If we put the cpu_core_map into the per cpu area then it will be allocated
          for each processor as it comes online.
      
          This means that the core map cannot be accessed until the per cpu area
          has been allocated. Xen does a weird thing here looping over all processors
          and zeroing the masks that are not yet allocated and that will be zeroed
          when they are allocated. I commented the code out.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08357611
  27. 11 10月, 2007 2 次提交
  28. 22 7月, 2007 1 次提交