1. 04 1月, 2011 1 次提交
    • C
      x86, UV, BAU: Extend for more than 16 cpus per socket · cfa60917
      Cliff Wickman 提交于
      Fix a hard-coded limit of a maximum of 16 cpu's per socket.
      
      The UV Broadcast Assist Unit code initializes by scanning the
      cpu topology of the system and assigning a master cpu for each
      socket and UV hub. That scan had an assumption of a limit of 16
      cpus per socket. With Westmere we are going over that limit.
      The UV hub hardware will allow up to 32.
      
      If the scan finds the system has gone over that limit it returns
      an error and we print a warning and fall back to doing TLB
      shootdowns without the BAU.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: <stable@kernel.org> # .37.x
      LKML-Reference: <E1PZol7-0000mM-77@eag09.americas.sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cfa60917
  2. 18 12月, 2010 1 次提交
  3. 08 12月, 2010 1 次提交
  4. 28 11月, 2010 1 次提交
  5. 25 11月, 2010 1 次提交
  6. 18 11月, 2010 2 次提交
    • J
      x86-64: Fix and clean up AMD Fam10 MMCONF enabling · 37db6c8f
      Jan Beulich 提交于
      Candidate memory ranges were not calculated properly (start
      addresses got needlessly rounded down, and end addresses didn't
      get rounded up at all), address comparison for secondary CPUs
      was done on only part of the address, and disabled status wasn't
      tracked properly.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      LKML-Reference: <4CE24DF40200007800022737@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      37db6c8f
    • 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
  7. 13 11月, 2010 1 次提交
  8. 11 11月, 2010 1 次提交
    • S
      tracing: Force arch_local_irq_* notrace for paravirt · b5908548
      Steven Rostedt 提交于
      When running ktest.pl randconfig tests, I would sometimes trigger
      a lockdep annotation bug (possible reason: unannotated irqs-on).
      
      This triggering happened right after function tracer self test was
      executed. After doing a config bisect I found that this was caused with
      having function tracer, paravirt guest, prove locking, and rcu torture
      all enabled.
      
      The rcu torture just enhanced the likelyhood of triggering the bug.
      Prove locking was needed, since it was the thing that was bugging.
      Function tracer would trace and disable interrupts in all sorts
      of funny places.
      paravirt guest would turn arch_local_irq_* into functions that would
      be traced.
      
      Besides the fact that tracing arch_local_irq_* is just a bad idea,
      this is what is happening.
      
      The bug happened simply in the local_irq_restore() code:
      
      		if (raw_irqs_disabled_flags(flags)) {	\
      			raw_local_irq_restore(flags);	\
      			trace_hardirqs_off();		\
      		} else {				\
      			trace_hardirqs_on();		\
      			raw_local_irq_restore(flags);	\
      		}					\
      
      The raw_local_irq_restore() was defined as arch_local_irq_restore().
      
      Now imagine, we are about to enable interrupts. We go into the else
      case and call trace_hardirqs_on() which tells lockdep that we are enabling
      interrupts, so it sets the current->hardirqs_enabled = 1.
      
      Then we call raw_local_irq_restore() which calls arch_local_irq_restore()
      which gets traced!
      
      Now in the function tracer we disable interrupts with local_irq_save().
      This is fine, but flags is stored that we have interrupts disabled.
      
      When the function tracer calls local_irq_restore() it does it, but this
      time with flags set as disabled, so we go into the if () path.
      This keeps interrupts disabled and calls trace_hardirqs_off() which
      sets current->hardirqs_enabled = 0.
      
      When the tracer is finished and proceeds with the original code,
      we enable interrupts but leave current->hardirqs_enabled as 0. Which
      now breaks lockdeps internal processing.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b5908548
  9. 10 11月, 2010 2 次提交
    • J
      x86, UV: Update node controller MMRs · 62b0cfc2
      Jack Steiner 提交于
      A new version of the SGI UV hub node controller is being
      developed. A few of the MMRs (control registers) that exist on
      the current hub no longer exist on the new hub. Fortunately,
      there are alternate MMRs that are are functionally equivalent
      and that exist on both hubs.
      
      This patch changes the UV code to use MMRs that exist in BOTH
      versions of the hub node controller.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20101106204056.GA27584@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      62b0cfc2
    • A
      x86: Address gcc4.6 "set but not used" warnings in apic.h · 0059b243
      Andi Kleen 提交于
      native_apic_msr_read() and x2apic_enabled() use rdmsr(msr, low, high),
      but only use the low part.
      
      gcc4.6 complains about this:
      .../apic.h:144:11: warning: variable 'high' set but not used [-Wunused-but-set-variable]
      
      rdmsr() is just a wrapper around rdmsrl() which splits the 64bit value
      into low and high, so using rdmsrl() directly solves this.
      
      [tglx: Changed the variables to u64 as suggested by Cyrill. It's less
             confusing and has no code impact as this is 64bit only anyway.
             Massaged changelog as well. ]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Cc: x86@kernel.org
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      LKML-Reference: <1289251229-19589-1-git-send-email-andi@firstfloor.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      0059b243
  10. 27 10月, 2010 4 次提交
    • B
      x86-32: Allocate irq stacks seperate from percpu area · 22d4cd4c
      Brian Gerst 提交于
      The percpu allocator cannot handle alignments larger than one
      page. Allocate the irq stacks seperately, and only keep the
      pointers as percpu data.
      Signed-off-by: NBrian Gerst <brgerst@gmail.com>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: tj@kernel.org
      LKML-Reference: <1288158182-1753-1-git-send-email-brgerst@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      22d4cd4c
    • P
      mm: remove pte_*map_nested() · ece0e2b6
      Peter Zijlstra 提交于
      Since we no longer need to provide KM_type, the whole pte_*map_nested()
      API is now redundant, remove it.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ece0e2b6
    • P
      mm: stack based kmap_atomic() · 3e4d3af5
      Peter Zijlstra 提交于
      Keep the current interface but ignore the KM_type and use a stack based
      approach.
      
      The advantage is that we get rid of crappy code like:
      
      	#define __KM_PTE			\
      		(in_nmi() ? KM_NMI_PTE : 	\
      		 in_irq() ? KM_IRQ_PTE :	\
      		 KM_PTE0)
      
      and in general can stop worrying about what context we're in and what kmap
      slots might be appropriate for that.
      
      The downside is that FRV kmap_atomic() gets more expensive.
      
      For now we use a CPP trick suggested by Andrew:
      
        #define kmap_atomic(page, args...) __kmap_atomic(page)
      
      to avoid having to touch all kmap_atomic() users in a single patch.
      
      [ not compiled on:
        - mn10300: the arch doesn't actually build with highmem to begin with ]
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
      Acked-by: NRik van Riel <riel@redhat.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3e4d3af5
    • R
      x86, uv: Enable Westmere support on SGI UV · c8f730b1
      Russ Anderson 提交于
      Enable Westmere support on SGI UV.  The UV initialization code is dependent on
      the APICID bits.  Westmere-EX uses different APIC bit mapping than Nehalem-EX.
      This code reads the apic shift value from a UV MMR to do the proper bit
      decoding to determint the pnode.
      Signed-off-by: NRuss Anderson <rja@sgi.com>
      LKML-Reference: <20101026212728.GB15071@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      c8f730b1
  11. 24 10月, 2010 25 次提交