1. 05 1月, 2009 1 次提交
  2. 04 1月, 2009 1 次提交
    • M
      x86: cleanup remaining cpumask_t ops in smpboot code · c2d1cec1
      Mike Travis 提交于
      Impact: use new cpumask API to reduce memory and stack usage
      
      Allocate the following local cpumasks based on the number of cpus that
      are present.  References will use new cpumask API.  (Currently only
      modified for x86_64, x86_32 continues to use the *_map variants.)
      
          cpu_callin_mask
          cpu_callout_mask
          cpu_initialized_mask
          cpu_sibling_setup_mask
      
      Provide the following accessor functions:
      
          struct cpumask *cpu_sibling_mask(int cpu)
          struct cpumask *cpu_core_mask(int cpu)
      
      Other changes are when setting or clearing the cpu online, possible
      or present maps, use the accessor functions.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c2d1cec1
  3. 17 12月, 2008 2 次提交
  4. 12 12月, 2008 1 次提交
  5. 11 11月, 2008 1 次提交
    • I
      x86: call machine_shutdown and stop all CPUs in native_machine_halt · d3ec5cae
      Ivan Vecera 提交于
      Impact: really halt all CPUs on halt
      
      Function machine_halt (resp. native_machine_halt) is empty for x86
      architectures. When command 'halt -f' is invoked, the message "System
      halted." is displayed but this is not really true because all CPUs are
      still running.
      
      There are also similar inconsistencies for other arches (some uses
      power-off for halt or forever-loop with IRQs enabled/disabled).
      
      IMO there should be used the same approach for all architectures OR
      what does the message "System halted" really mean?
      
      This patch fixes it for x86.
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d3ec5cae
  6. 25 8月, 2008 1 次提交
  7. 06 7月, 2008 1 次提交
  8. 26 6月, 2008 2 次提交
  9. 14 5月, 2008 1 次提交
    • H
      x86: fix app crashes after SMP resume · 61165d7a
      Hugh Dickins 提交于
      After resume on a 2cpu laptop, kernel builds collapse with a sed hang,
      sh or make segfault (often on 20295564), real-time signal to cc1 etc.
      
      Several hurdles to jump, but a manually-assisted bisect led to -rc1's
      d2bcbad5 x86: do not zap_low_mappings
      in __smp_prepare_cpus.  Though the low mappings were removed at bootup,
      they were left behind (with Global flags helping to keep them in TLB)
      after resume or cpu online, causing the crashes seen.
      
      Reinstate zap_low_mappings (with local __flush_tlb_all) for each cpu_up
      on x86_32.  This used to be serialized by smp_commenced_mask: that's now
      gone, but a low_mappings flag will do.  No need for native_smp_cpus_done
      to repeat the zap: let mem_init zap BSP's low mappings just like on UP.
      
      (In passing, fix error code from native_cpu_up: do_boot_cpu returns a
      variety of diagnostic values, Dprintk what it says but convert to -EIO.
      And save_pg_dir separately before zap_low_mappings: doesn't matter now,
      but zapping twice in succession wiped out resume's swsusp_pg_dir.)
      
      That worked well on the duo and one quad, but wouldn't boot 3rd or 4th
      cpu on P4 Xeon, oopsing just after unlock_ipi_call_lock.  The TLB flush
      IPI now being sent reveals a long-standing bug: the booting cpu has its
      APIC readied in smp_callin at the top of start_secondary, but isn't put
      into the cpu_online_map until just before that unlock_ipi_call_lock.
      
      So native_smp_call_function_mask to online cpus would send_IPI_allbutself,
      including the cpu just coming up, though it has been excluded from the
      count to wait for: by the time it handles the IPI, the call data on
      native_smp_call_function_mask's stack may well have been overwritten.
      
      So fall back to send_IPI_mask while cpu_online_map does not match
      cpu_callout_map: perhaps there's a better APICological fix to be
      made at the start_secondary end, but I wouldn't know that.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      61165d7a
  10. 17 4月, 2008 4 次提交