1. 18 7月, 2008 1 次提交
    • S
      sparc: copy sparc64 specific files to asm-sparc · a00736e9
      Sam Ravnborg 提交于
      Used the following script to copy the files:
      cd include
      set -e
      SPARC64=`ls asm-sparc64`
      for FILE in ${SPARC64}; do
      	if [ -f asm-sparc/$FILE ]; then
      		echo $FILE exist in asm-sparc
      	else
      		git mv asm-sparc64/$FILE asm-sparc/$FILE
      		printf "#include <asm-sparc/$FILE>\n" > asm-sparc64/$FILE
      		git add asm-sparc64/$FILE
      	fi
      done
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      a00736e9
  2. 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
  3. 27 10月, 2007 1 次提交
  4. 09 8月, 2007 1 次提交
  5. 20 3月, 2006 1 次提交
  6. 25 7月, 2005 1 次提交
  7. 28 6月, 2005 1 次提交
    • D
      [SPARC64]: Avoid membar instructions in delay slots. · b445e26c
      David S. Miller 提交于
      In particular, avoid membar instructions in the delay
      slot of a jmpl instruction.
      
      UltraSPARC-I, II, IIi, and IIe have a bug, documented in
      the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
      
      The long and short of it is that if the IMU unit misses
      on a branch or jmpl, and there is a store buffer synchronizing
      membar in the delay slot, the chip can stop fetching instructions.
      
      If interrupts are enabled or some other trap is enabled, the
      chip will unwedge itself, but performance will suffer.
      
      We already had a workaround for this bug in a few spots, but
      it's better to have the entire tree sanitized for this rule.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b445e26c
  8. 24 5月, 2005 1 次提交
    • D
      [SPARC64]: Add boot option to force UltraSPARC-III P-Cache on. · 816242da
      David S. Miller 提交于
      Older UltraSPARC-III chips have a P-Cache bug that makes us disable it
      by default at boot time.
      
      However, this does hurt performance substantially, particularly with
      memcpy(), and the bug is _incredibly_ obscure.  I have never seen it
      triggered in practice, ever.
      
      So provide a "-P" boot option that forces the P-Cache on.  It taints
      the kernel, so if it does trigger and cause some data corruption or
      OOPS, we will find out in the logs that this option was on when it
      happened.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      816242da
  9. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4