1. 26 3月, 2008 29 次提交
  2. 25 3月, 2008 2 次提交
  3. 24 3月, 2008 7 次提交
  4. 23 3月, 2008 1 次提交
    • T
      x86: revert: reserve dma32 early for gart · 9e963048
      Thomas Gleixner 提交于
      Revert
      
      commit f62f1fc9
      Author: Yinghai Lu <yhlu.kernel@gmail.com>
      Date:   Fri Mar 7 15:02:50 2008 -0800
      
          x86: reserve dma32 early for gart
      
      The patch has a dependency on bootmem modifications which are not .25
      material that late in the -rc cycle. The problem which is addressed by
      the patch is limited to machines with 256G and more memory booted with
      NUMA disabled. This is not a .25 regression and the audience which is
      affected by this problem is very limited, so it's safer to do the
      revert than pulling in intrusive bootmem changes right now.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9e963048
  5. 22 3月, 2008 1 次提交
    • D
      [SPARC64]: Remove most limitations to kernel image size. · 64658743
      David S. Miller 提交于
      Currently kernel images are limited to 8MB in size, and this causes
      problems especially when enabling features that take up a lot of
      kernel image space such as lockdep.
      
      The code now will align the kernel image size up to 4MB and map that
      many locked TLB entries.  So, the only practical limitation is the
      number of available locked TLB entries which is 16 on Cheetah and 64
      on pre-Cheetah sparc64 cpus.  Niagara cpus don't actually have hw
      locked TLB entry support.  Rather, the hypervisor transparently
      provides support for "locked" TLB entries since it runs with physical
      addressing and does the initial TLB miss processing.
      
      Fully utilizing this change requires some help from SILO, a patch for
      which will be submitted to the maintainer.  Essentially, SILO will
      only currently map up to 8MB for the kernel image and that needs to be
      increased.
      
      Note that neither this patch nor the SILO bits will help with network
      booting.  The openfirmware code will only map up to a certain amount
      of kernel image during a network boot and there isn't much we can to
      about that other than to implemented a layered network booting
      facility.  Solaris has this, and calls it "wanboot" and we may
      implement something similar at some point.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64658743
新手
引导
客服 返回
顶部