1. 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
  2. 28 4月, 2008 1 次提交
  3. 26 4月, 2008 1 次提交
    • D
      x86: remove NexGen support · f7f17a67
      Dmitri Vorobiev 提交于
      It is claimed that NexGen CPUs were never shipped:
      
         http://lkml.org/lkml/2008/4/20/179
      
      Also, the kernel support for these chips has been broken for
      a long time, the code intended to support NexGen thereby being
      essentially dead.
      
      As an outcome of the discussion that can be found using the URL
      above, this patch removes the NexGen support altogether.
      
      The changes in this patch survived a defconfig build for i386, a
      couple of successful randconfig builds, as well as a runtime test,
      which consisted in booting a 32-bit x86 box up to the shell prompt.
      Signed-off-by: NDmitri Vorobiev <dmitri.vorobiev@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f7f17a67
  4. 25 4月, 2008 3 次提交
  5. 20 4月, 2008 1 次提交
  6. 17 4月, 2008 4 次提交
  7. 15 2月, 2008 1 次提交
  8. 10 2月, 2008 2 次提交
    • T
      x86: introduce page pool in cpa · 76ebd054
      Thomas Gleixner 提交于
      DEBUG_PAGEALLOC was not possible on 64-bit due to its early-bootup
      hardcoded reliance on PSE pages, and the unrobustness of the runtime
      splitup of large pages. The splitup ended in recursive calls to
      alloc_pages() when a page for a pte split was requested.
      
      Avoid the recursion with a preallocated page pool, which is used to
      split up large mappings and gets refilled in the return path of
      kernel_map_pages after the split has been done. The size of the page
      pool is adjusted to the available memory.
      
      This part just implements the page pool and the initialization w/o
      using it yet.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      76ebd054
    • I
      x86: construct 32-bit boot time page tables in native format. · 551889a6
      Ian Campbell 提交于
      Specifically the boot time page tables in a CONFIG_X86_PAE=y enabled
      kernel are in PAE format.
      
      early_ioremap is updated to use the standard page table accessors.
      
      Clear any mappings beyond max_low_pfn from the boot page tables in
      native_pagetable_setup_start because the initial mappings can extend
      beyond the range of physical memory and into the vmalloc area.
      
      Derived from patches by Eric Biederman and H. Peter Anvin.
      
      [ jeremy@goop.org: PAE swapper_pg_dir needs to be page-sized fix ]
      Signed-off-by: NIan Campbell <ijc@hellion.org.uk>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Mika Penttilä <mika.penttila@kolumbus.fi>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      551889a6
  9. 04 2月, 2008 1 次提交
  10. 02 2月, 2008 1 次提交
  11. 30 1月, 2008 22 次提交
  12. 15 1月, 2008 1 次提交
    • I
      x86: fix boot crash on HIGHMEM4G && SPARSEMEM · 23be8c7d
      Ingo Molnar 提交于
      Denys Fedoryshchenko reported a bootup crash when he upgraded
      his system from 3GB to 4GB RAM:
      
         http://lkml.org/lkml/2008/1/7/9
      
      the bug is due to HIGHMEM4G && SPARSEMEM kernels making pfn_to_page()
      to return an invalid pointer when the pfn is in a memory hole. The
      256 MB PCI aperture at the end of RAM was not mapped by sparsemem,
      and hence the pfn was not valid. But set_highmem_pages_init() iterated
      this range without checking the pfn's validity first.
      
      this bug was probably present in the sparsemem code ever since sparsemem
      has been introduced in v2.6.13. It was masked due to HIGHMEM64G using
      larger memory regions in sparsemem_32.h:
      
       #ifdef CONFIG_X86_PAE
       #define SECTION_SIZE_BITS       30
       #define MAX_PHYSADDR_BITS       36
       #define MAX_PHYSMEM_BITS        36
       #else
       #define SECTION_SIZE_BITS       26
       #define MAX_PHYSADDR_BITS       32
       #define MAX_PHYSMEM_BITS        32
       #endif
      
      which creates 1GB sparsemem regions instead of 64MB sparsemem regions.
      So in practice we only ever created true sparsemem holes on x86 with
      HIGHMEM4G - but that was rarely used by distros.
      
      ( btw., we could probably save 2MB of mem_map[]s on X86_PAE if we reduced
        the sparsemem region size to 256 MB. )
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      23be8c7d
  13. 18 10月, 2007 1 次提交
    • I
      x86: fix CONFIG_PAGEALLOC related boot hangs/OOMs · 509a80c4
      Ingo Molnar 提交于
      if CONFIG_PAGEALLOC is enabled then X86_FEATURE_PSE is disabled and all
      the kernel physical RAM pagetables are set up as 4K pages. This is
      needed so that CONFIG_PAGEALLOC can do finegrained mapping and unmapping
      of pages.
      
      as a side-effect though, the total size of memory allocated as kernel
      pagetables increases significantly. All these pagetables are allocated
      via alloc_bootmem_low_pages(), straight out of the lowmem DMA pool. If
      the system has enough RAM and a large kernel image then almost all of
      the 16 MB lowmem DMA pool is allocated to the image and to pagetables -
      leaving no space for __GFP_DMA allocations.
      
      this results in drivers failing and the bootup hanging:
      
       swapper invoked oom-killer: gfp_mask=0x80d1, order=0, oomkilladj=0
        [<4015059f>] out_of_memory+0x17f/0x1c0
        [<40151f3c>] __alloc_pages+0x37c/0x3a0
        [<40168cd7>] slob_new_page+0x37/0x50
        [<40168dff>] slob_alloc+0x10f/0x190
        [<40169010>] __kmalloc_node+0x80/0x90
        [<405a17e3>] scsi_host_alloc+0x33/0x2c0
        [<405a1a82>] scsi_register+0x12/0x60
        [<40d5889e>] aha1542_detect+0x9e/0x940
        [<405c5ba5>] ultrastor_detect+0x265/0x5f0
        [<401352f5>] getnstimeofday+0x35/0xf0
        [<40d58751>] init_this_scsi_driver+0x41/0xf0
        [<40d0b856>] kernel_init+0x136/0x310
        [<40d58710>] init_this_scsi_driver+0x0/0xf0
        [<40d0b720>] kernel_init+0x0/0x310
        [<40105547>] kernel_thread_helper+0x7/0x10
        =======================
      
      the fix is to first allocate from above the DMA pool, and if that fails
      (for example due to it being a machine with less than 16 MB of RAM),
      allocate from the DMA pool as a fallback.
      
      With this fix applied i was able to boot a PAGEALLOC=y kernel that would
      hang before.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      509a80c4