1. 06 5月, 2009 2 次提交
  2. 29 4月, 2009 1 次提交
  3. 23 4月, 2009 1 次提交
    • Y
      x86: check boundary in setup_node_bootmem() · 4c31e92b
      Yinghai Lu 提交于
      Commit dc098551 ("x86/uv: fix init of memory-less nodes") causes a
      two sockets system (where node-1 doesn't have RAM installed) to crash.
      
      That commit makes node_possible include cpu nodes that do not have memory.
      So check boundary in setup_node_bootmem().
      
      [ Impact: fix boot crash on RAM-less NUMA node system ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Jack Steiner <steiner@sgi.com>
      LKML-Reference: <49EF89DF.9090404@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4c31e92b
  4. 18 4月, 2009 2 次提交
    • J
      x86: mm/numa_32.c calculate_numa_remap_pages should use __init · a81b6314
      Jaswinder Singh Rajput 提交于
      calculate_numa_remap_pages() is called only by __init initmem_init()
      further calculate_numa_remap_pages is calling:
      	__init find_e820_area() and __init reserve_early()
      
      So calculate_numa_remap_pages() should be __init calculate_numa_remap_pages().
      
       WARNING: arch/x86/built-in.o(.text+0x82ea3): Section mismatch in reference from the function calculate_numa_remap_pages() to the function .init.text:find_e820_area()
       The function calculate_numa_remap_pages() references
       the function __init find_e820_area().
       This is often because calculate_numa_remap_pages lacks a __init
       annotation or the annotation of find_e820_area is wrong.
      
       WARNING: arch/x86/built-in.o(.text+0x82f5f): Section mismatch in reference from the function calculate_numa_remap_pages() to the function .init.text:reserve_early()
       The function calculate_numa_remap_pages() references
       the function __init reserve_early().
       This is often because calculate_numa_remap_pages lacks a __init
       annotation or the annotation of reserve_early is wrong.
      
      [ Impact: save memory, address Section mismatch warning ]
      Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      LKML-Reference: <1239991281.3153.4.camel@ht.satnam>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a81b6314
    • J
      x86/uv: fix init of memory-less nodes · dc098551
      Jack Steiner 提交于
      Add support for nodes that have cpus but no memory.
      The current code was failing to add these nodes
      to the nodes_present_map.
      
      v2: Fixes case caught by David Rientjes - missed support
          for the x2apic SRAT table.
      
      [ Impact: fix potential boot crash on memory-less UV nodes. ]
      Reported-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090417142242.GA23743@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc098551
  5. 17 4月, 2009 1 次提交
  6. 12 4月, 2009 1 次提交
    • M
      x86: fix wrong section of pat_disable & make it static · 1ee4bd92
      Marcin Slusarz 提交于
      pat_disable cannot be __cpuinit anymore because it's called from pat_init
      and the callchain looks like this:
      pat_disable [cpuinit] <- pat_init <- generic_set_all <-
       ipi_handler <- set_mtrr <- (other non init/cpuinit functions)
      
      WARNING: arch/x86/mm/built-in.o(.text+0x449e): Section mismatch in reference
      from the function pat_init() to the function .cpuinit.text:pat_disable()
      The function pat_init() references
      the function __cpuinit pat_disable().
      This is often because pat_init lacks a __cpuinit
      annotation or the annotation of pat_disable is wrong.
      
      Non CONFIG_X86_PAT version of pat_disable is static inline, so this version
      can be static too (and there are no callers outside of this file).
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      LKML-Reference: <49DFB055.6070405@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1ee4bd92
  7. 11 4月, 2009 1 次提交
  8. 10 4月, 2009 8 次提交
  9. 04 4月, 2009 3 次提交
  10. 02 4月, 2009 1 次提交
  11. 01 4月, 2009 2 次提交
  12. 25 3月, 2009 1 次提交
  13. 22 3月, 2009 1 次提交
  14. 20 3月, 2009 3 次提交
  15. 19 3月, 2009 1 次提交
  16. 18 3月, 2009 2 次提交
    • R
      x86: cpumask: x86 mmio-mod.c use cpumask_var_t for downed_cpus · c38da569
      Rusty Russell 提交于
      Impact: cleanup, reduce memory usage for CONFIG_CPUMASK_OFFSTACK=y
      
      Part of the "getting rid of obsolete cpumask_t" patch:
      
       1) Use cpumask_var_t: this is a pointer if CONFIG_CPUMASK_OFFSTACK=y
       2) Call alloc_cpumask_var() on first entry into enter_uniprocessor()
       3) Use modern cpumask_* functions.
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Pekka Paalanen <pq@iki.fi>
      LKML-Reference: <200903111633.55952.rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c38da569
    • S
      x86: add x2apic_wrmsr_fence() to x2apic flush tlb paths · ce4e240c
      Suresh Siddha 提交于
      Impact: optimize APIC IPI related barriers
      
      Uncached MMIO accesses for xapic are inherently serializing and hence
      we don't need explicit barriers for xapic IPI paths.
      
      x2apic MSR writes/reads don't have serializing semantics and hence need
      a serializing instruction or mfence, to make all the previous memory
      stores globally visisble before the x2apic msr write for IPI.
      
      Add x2apic_wrmsr_fence() in flush tlb path to x2apic specific paths.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: "steiner@sgi.com" <steiner@sgi.com>
      Cc: Nick Piggin <npiggin@suse.de>
      LKML-Reference: <1237313814.27006.203.camel@localhost.localdomain>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ce4e240c
  17. 16 3月, 2009 1 次提交
  18. 15 3月, 2009 1 次提交
    • J
      x86: add brk allocation for very, very early allocations · 93dbda7c
      Jeremy Fitzhardinge 提交于
      Impact: new interface
      
      Add a brk()-like allocator which effectively extends the bss in order
      to allow very early code to do dynamic allocations.  This is better than
      using statically allocated arrays for data in subsystems which may never
      get used.
      
      The space for brk allocations is in the bss ELF segment, so that the
      space is mapped properly by the code which maps the kernel, and so
      that bootloaders keep the space free rather than putting a ramdisk or
      something into it.
      
      The bss itself, delimited by __bss_stop, ends before the brk area
      (__brk_base to __brk_limit).  The kernel text, data and bss is reserved
      up to __bss_stop.
      
      Any brk-allocated data is reserved separately just before the kernel
      pagetable is built, as that code allocates from unreserved spaces
      in the e820 map, potentially allocating from any unused brk memory.
      Ultimately any unused memory in the brk area is used in the general
      kernel memory pool.
      
      Initially the brk space is set to 1MB, which is probably much larger
      than any user needs (the largest current user is i386 head_32.S's code
      to build the pagetables to map the kernel, which can get fairly large
      with a big kernel image and no PSE support).  So long as the system
      has sufficient memory for the bootloader to reserve the kernel+1MB brk,
      there are no bad effects resulting from an over-large brk.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      93dbda7c
  19. 13 3月, 2009 7 次提交