1. 01 9月, 2009 2 次提交
    • T
      x86: apic namespace cleanup · e11dadab
      Thomas Gleixner 提交于
      boot_cpu_physical_apicid is a global variable and used as function
      argument as well. Rename the function arguments to avoid confusion.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      e11dadab
    • T
      x86: Distangle ioapic and i8259 · bc07844a
      Thomas Gleixner 提交于
      The proposed Moorestown support patches use an extra feature flag
      mechanism to make the ioapic work w/o an i8259. There is a much
      simpler solution.
      
      Most i8259 specific functions are already called dependend on the irq
      number less than NR_IRQS_LEGACY. Replacing that constant by a
      read_mostly variable which can be set to 0 by the platform setup code
      allows us to achieve the same without any special feature flags.
      
      That trivial change allows us to proceed with MRST w/o doing a full
      blown overhaul of the ioapic code which would delay MRST unduly.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      bc07844a
  2. 31 8月, 2009 23 次提交
  3. 27 8月, 2009 11 次提交
  4. 25 8月, 2009 2 次提交
    • J
      x86: Fix build with older binutils and consolidate linker script · c62e4320
      Jan Beulich 提交于
      binutils prior to 2.17 can't deal with the currently possible
      situation of a new segment following the per-CPU segment, but
      that new segment being empty - objcopy misplaces the .bss (and
      perhaps also the .brk) sections outside of any segment.
      
      However, the current ordering of sections really just appears
      to be the effect of cumulative unrelated changes; re-ordering
      things allows to easily guarantee that the segment following
      the per-CPU one is non-empty, and at once eliminates the need
      for the bogus data.init2 segment.
      
      Once touching this code, also use the various data section
      helper macros from include/asm-generic/vmlinux.lds.h.
      
      -v2: fix !SMP builds.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: <sam@ravnborg.org>
      LKML-Reference: <4A94085D02000078000119A5@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c62e4320
    • A
      x86: Fix an incorrect argument of reserve_bootmem() · a6a06f7b
      Amerigo Wang 提交于
      This line looks suspicious, because if this is true, then the
      'flags' parameter of function reserve_bootmem_generic() will be
      unused when !CONFIG_NUMA. I don't think this is what we want.
      Signed-off-by: NWANG Cong <amwang@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: akpm@linux-foundation.org
      LKML-Reference: <20090821083709.5098.52505.sendpatchset@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a6a06f7b
  5. 24 8月, 2009 1 次提交
  6. 22 8月, 2009 1 次提交
    • L
      x86: don't call '->send_IPI_mask()' with an empty mask · b04e6373
      Linus Torvalds 提交于
      As noted in 83d349f3 ("x86: don't send
      an IPI to the empty set of CPU's"), some APIC's will be very unhappy
      with an empty destination mask.  That commit added a WARN_ON() for that
      case, and avoided the resulting problem, but didn't fix the underlying
      reason for why those empty mask cases happened.
      
      This fixes that, by checking the result of 'cpumask_andnot()' of the
      current CPU actually has any other CPU's left in the set of CPU's to be
      sent a TLB flush, and not calling down to the IPI code if the mask is
      empty.
      
      The reason this started happening at all is that we started passing just
      the CPU mask pointers around in commit 4595f962 ("x86: change
      flush_tlb_others to take a const struct cpumask"), and when we did that,
      the cpumask was no longer thread-local.
      
      Before that commit, flush_tlb_mm() used to create it's own copy of
      'mm->cpu_vm_mask' and pass that copy down to the low-level flush
      routines after having tested that it was not empty.  But after changing
      it to just pass down the CPU mask pointer, the lower level TLB flush
      routines would now get a pointer to that 'mm->cpu_vm_mask', and that
      could still change - and become empty - after the test due to other
      CPU's having flushed their own TLB's.
      
      See
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13933
      
      for details.
      Tested-by: NThomas Björnell <thomas.bjornell@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b04e6373