1. 16 1月, 2018 1 次提交
  2. 17 10月, 2017 1 次提交
  3. 22 3月, 2017 1 次提交
  4. 01 2月, 2017 1 次提交
  5. 04 5月, 2016 13 次提交
  6. 13 9月, 2015 1 次提交
    • G
      x86/platform/uv: Insert per_cpu accessor function on uv_hub_nmi · 7c52198b
      George Beshers 提交于
      UV: NMI: insert this_cpu_read accessor function on uv_hub_nmi.
      
      On SGI UV systems a 'power nmi' command from the CMC causes
      all processors to drop into uv_handle_nmi().  With the 4.0
      kernel this results in
      
          BUG: unable to handle kernel paging request
      
      The bug is caused by the current code trying to use the PER_CPU
      variable uv_cpu_nmi.hub without an appropriate accessor
      function. That oversight occurred in
      
          commit e1632170 ("uv: Replace __get_cpu_var")
          Author: Christoph Lameter <cl@linux.com>
          Date:   Sun Aug 17 12:30:41 2014 -0500
      
      This patch inserts this_cpu_read() in the uv_hub_nmi macro
      restoring the intended functionality.
      Signed-off-by: NGeorge Beshers <gbeshers@sgi.com>
      Acked-by: NMike Travis <travis@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Hedi Berriche <hedi@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      7c52198b
  7. 27 8月, 2014 2 次提交
    • C
      uv: Replace __get_cpu_var · e1632170
      Christoph Lameter 提交于
      Use __this_cpu_read instead.
      
      Cc: Hedi Berriche <hedi@sgi.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      e1632170
    • C
      x86: Replace __get_cpu_var uses · 89cbc767
      Christoph Lameter 提交于
      __get_cpu_var() is used for multiple purposes in the kernel source. One of
      them is address calculation via the form &__get_cpu_var(x).  This calculates
      the address for the instance of the percpu variable of the current processor
      based on an offset.
      
      Other use cases are for storing and retrieving data from the current
      processors percpu area.  __get_cpu_var() can be used as an lvalue when
      writing data or on the right side of an assignment.
      
      __get_cpu_var() is defined as :
      
      #define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
      
      __get_cpu_var() always only does an address determination. However, store
      and retrieve operations could use a segment prefix (or global register on
      other platforms) to avoid the address calculation.
      
      this_cpu_write() and this_cpu_read() can directly take an offset into a
      percpu area and use optimized assembly code to read and write per cpu
      variables.
      
      This patch converts __get_cpu_var into either an explicit address
      calculation using this_cpu_ptr() or into a use of this_cpu operations that
      use the offset.  Thereby address calculations are avoided and less registers
      are used when code is generated.
      
      Transformations done to __get_cpu_var()
      
      1. Determine the address of the percpu instance of the current processor.
      
      	DEFINE_PER_CPU(int, y);
      	int *x = &__get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(&y);
      
      2. Same as #1 but this time an array structure is involved.
      
      	DEFINE_PER_CPU(int, y[20]);
      	int *x = __get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(y);
      
      3. Retrieve the content of the current processors instance of a per cpu
      variable.
      
      	DEFINE_PER_CPU(int, y);
      	int x = __get_cpu_var(y)
      
         Converts to
      
      	int x = __this_cpu_read(y);
      
      4. Retrieve the content of a percpu struct
      
      	DEFINE_PER_CPU(struct mystruct, y);
      	struct mystruct x = __get_cpu_var(y);
      
         Converts to
      
      	memcpy(&x, this_cpu_ptr(&y), sizeof(x));
      
      5. Assignment to a per cpu variable
      
      	DEFINE_PER_CPU(int, y)
      	__get_cpu_var(y) = x;
      
         Converts to
      
      	__this_cpu_write(y, x);
      
      6. Increment/Decrement etc of a per cpu variable
      
      	DEFINE_PER_CPU(int, y);
      	__get_cpu_var(y)++
      
         Converts to
      
      	__this_cpu_inc(y)
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: x86@kernel.org
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      89cbc767
  8. 01 4月, 2014 1 次提交
  9. 24 9月, 2013 1 次提交
    • M
      x86/UV: Update UV support for external NMI signals · 0d12ef0c
      Mike Travis 提交于
      The current UV NMI handler has not been updated for the changes
      in the system NMI handler and the perf operations.  The UV NMI
      handler reads an MMR in the UV Hub to check to see if the NMI
      event was caused by the external 'system NMI' that the operator
      can initiate on the System Mgmt Controller.
      
      The problem arises when the perf tools are running, causing
      millions of perf events per second on very large CPU count
      systems.  Previously this was okay because the perf NMI handler
      ran at a higher priority on the NMI call chain and if the NMI
      was a perf event, it would stop calling other NMI handlers
      remaining on the NMI call chain.
      
      Now the system NMI handler calls all the handlers on the NMI
      call chain including the UV NMI handler.  This causes the UV NMI
      handler to read the MMRs at the same millions per second rate.
      This can lead to significant performance loss and possible
      system failures.  It also can cause thousands of 'Dazed and
      Confused' messages being sent to the system console.  This
      effectively makes perf tools unusable on UV systems.
      
      To avoid this excessive overhead when perf tools are running,
      this code has been optimized to minimize reading of the MMRs as
      much as possible, by moving to the NMI_UNKNOWN notifier chain.
      This chain is called only when all the users on the standard
      NMI_LOCAL call chain have been called and none of them have
      claimed this NMI.
      
      There is an exception where the NMI_LOCAL notifier chain is
      used.  When the perf tools are in use, it's possible that the UV
      NMI was captured by some other NMI handler and then either
      ignored or mistakenly processed as a perf event.  We set a
      per_cpu ('ping') flag for those CPUs that ignored the initial
      NMI, and then send them an IPI NMI signal.  The NMI_LOCAL
      handler on each cpu does not need to read the MMR, but instead
      checks the in memory flag indicating it was pinged.  There are
      two module variables, 'ping_count' indicating how many requested
      NMI events occurred, and 'ping_misses' indicating how many stray
      NMI events.  These most likely are perf events so it shows the
      overhead of the perf NMI interrupts and how many MMR reads were avoided.
      
      This patch also minimizes the reads of the MMRs by having the
      first cpu entering the NMI handler on each node set a per HUB
      in-memory atomic value.  (Having a per HUB value avoids sending
      lock traffic over NumaLink.)  Both types of UV NMIs from the SMI
      layer are supported.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NDimitri Sivanich <sivanich@sgi.com>
      Reviewed-by: NHedi Berriche <hedi@sgi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Link: http://lkml.kernel.org/r/20130923212500.353547733@asylum.americas.sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      0d12ef0c
  10. 12 2月, 2013 1 次提交
  11. 26 1月, 2012 1 次提交
  12. 21 9月, 2011 1 次提交
    • J
      x86: uv2: Workaround for UV2 Hub bug (system global address format) · 6a469e46
      Jack Steiner 提交于
      This is a workaround for a UV2 hub bug that affects the format of system
      global addresses.
      
      The GRU API for UV2 was inadvertently broken by a hardware change.  The
      format of the physical address used for TLB dropins and for addresses used
      with instructions running in unmapped mode has changed.  This change was
      not documented and became apparent only when diags failed running on
      system simulators.
      
      For UV1, TLB and GRU instruction physical addresses are identical to
      socket physical addresses (although high NASID bits must be OR'ed into the
      address).
      
      For UV2, socket physical addresses need to be converted.  The NODE portion
      of the physical address needs to be shifted so that the low bit is in bit
      39 or bit 40, depending on an MMR value.
      
      It is not yet clear if this bug will be fixed in a silicon respin.  If it
      is fixed, the hub revision will be incremented & the workaround disabled.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6a469e46
  13. 25 5月, 2011 1 次提交
  14. 10 5月, 2011 1 次提交
    • J
      x86, UV: Fix NMI handler for UV platforms · 1d44e828
      Jack Steiner 提交于
      This fixes problems seen on UV systems handling NMIs from the
      node controller.
      
      I isolated the "dazed..." messages that I saw earlier to a bug in
      the BMC on our platform. It was sending NMIs w/o properly setting
      a register that indicated the source of NMI.
      
      So rather than _assuming_ any unhandled NMI came from the UV system
      maintenance console (SMC), add a check to verify that the SMC actually
      sent the NMI.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: gorcunov@gmail.com
      Cc: dzickus@redhat.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1d44e828
  15. 18 11月, 2010 1 次提交
    • D
      x86: UV: Address interrupt/IO port operation conflict · 8191c9f6
      Dimitri Sivanich 提交于
      This patch for SGI UV systems addresses a problem whereby
      interrupt transactions being looped back from a local IOH,
      through the hub to a local CPU can (erroneously) conflict with
      IO port operations and other transactions.
      
      To workaound this we set a high bit in the APIC IDs used for
      interrupts. This bit appears to be ignored by the sockets, but
      it avoids the conflict in the hub.
      Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
      LKML-Reference: <20101116222352.GA8155@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ___
      
       arch/x86/include/asm/uv/uv_hub.h   |    4 ++++
       arch/x86/include/asm/uv/uv_mmrs.h  |   19 ++++++++++++++++++-
       arch/x86/kernel/apic/x2apic_uv_x.c |   25 +++++++++++++++++++++++--
       arch/x86/platform/uv/tlb_uv.c      |    2 +-
       arch/x86/platform/uv/uv_time.c     |    4 +++-
       5 files changed, 49 insertions(+), 5 deletions(-)
      8191c9f6
  16. 27 10月, 2010 1 次提交
  17. 17 4月, 2010 1 次提交
    • R
      x86, UV: uv_irq.c: Fix all sparse warnings · a289cc7c
      Randy Dunlap 提交于
      Fix all sparse warnings in building uv_irq.c.
      
       arch/x86/kernel/uv_irq.c:46:17: warning: symbol 'uv_irq_chip' was not declared. Should it be static?
       arch/x86/kernel/uv_irq.c:143:50: error: no identifier for function argument
       arch/x86/kernel/uv_irq.c:162:13: error: typename in expression
       arch/x86/kernel/uv_irq.c:162:13: error: undefined identifier 'restrict'
       arch/x86/kernel/uv_irq.c:250:44: error: no identifier for function argument
       arch/x86/kernel/uv_irq.c:260:17: error: typename in expression
       arch/x86/kernel/uv_irq.c:260:17: error: undefined identifier 'restrict'
       arch/x86/kernel/uv_irq.c:233:50: warning: incorrect type in argument 3 (different signedness)
       arch/x86/kernel/uv_irq.c:233:50:    expected int *pnode
       arch/x86/kernel/uv_irq.c:233:50:    got unsigned int *<noident>
       arch/x86/include/asm/uv/uv_hub.h:318:44: warning: incorrect type in argument 2 (different address spaces)
       arch/x86/include/asm/uv/uv_hub.h:318:44:    expected void volatile [noderef] <asn:2>*addr
       arch/x86/include/asm/uv/uv_hub.h:318:44:    got unsigned long *
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Dimitri Sivanich <sivanich@sgi.com>
      Cc: Russ Anderson <rja@sgi.com>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Mike Travis <travis@sgi.com>
      Cc: Cliff Wickman <cpw@sgi.com>
      Cc: Jack Steiner <steiner@sgi.com>
      LKML-Reference: <20100416175142.f4b59683.randy.dunlap@oracle.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a289cc7c
  18. 16 1月, 2010 1 次提交
  19. 08 1月, 2010 1 次提交
  20. 31 12月, 2009 1 次提交
  21. 29 12月, 2009 1 次提交
    • M
      x86: SGI UV: Fix writes to led registers on remote uv hubs · 39d30770
      Mike Travis 提交于
      The wrong address was being used to write the SCIR led regs on
      remote hubs.  Also, there was an inconsistency between how BIOS
      and the kernel indexed these regs.  Standardize on using the
      lower 6 bits of the APIC ID as the index.
      
      This patch fixes the problem of writing to an errant address to
      a cpu # >= 64.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Reviewed-by: NJack Steiner <steiner@sgi.com>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: stable@kernel.org
      LKML-Reference: <4B3922F9.3060905@sgi.com>
      [ v2: fix a number of annoying checkpatch artifacts and whitespace noise ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      39d30770
  22. 16 12月, 2009 3 次提交
  23. 21 10月, 2009 1 次提交
  24. 16 10月, 2009 1 次提交
  25. 18 9月, 2009 1 次提交