1. 25 5月, 2013 1 次提交
  2. 07 5月, 2013 1 次提交
    • H
      parisc: fix partly 16/64k PAGE_SIZE boot · 6a45716a
      Helge Deller 提交于
      This patch fixes partly PAGE_SIZEs of 16K or 64K by adjusting the
      assembler PTE lookup code and the assembler TEMPALIAS code.  Furthermore
      some data alignments for PAGE_SIZE have been limited to 4K (or less) to
      not waste too much memory with greater page sizes. As a side note, the
      palo loader can (currently) only handle up to 10 ELF segments which is
      fixed with tighter aligning as well.
      
      My testings indicated that the ldci command in the sba iommu coding
      needed adjustment by the PAGE_SHIFT value and that the I/O PDIR Page
      size was only set to 4K for my machine (C3000).
      
      All this fixes partly the boot, but there are still quite some caching
      problems left.  Examples are e.g. the symbios logic driver which is
      failing:
      
      sym0: <896> rev 0x7 at pci 0000:00:0f.0 irq 69
      sym0: PA-RISC Firmware, ID 7, Fast-40, SE, parity checking
      CACHE TEST FAILED: DMA error (dstat=0x81).sym0: CACHE INCORRECTLY CONFIGURED.
      
      and the tulip network driver which doesn't seem to work correctly
      either:
      
      Sending BOOTP requests .net eth0: Setting full-duplex based on MII#1
      link partner capability of 05e1
      ..... timed out!
      
      Beside those kernel fixes glibc will need fixes too to be able to handle
      >4K page sizes.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      6a45716a
  3. 21 2月, 2013 1 次提交
    • J
      parisc: fixes and cleanups in page cache flushing (2/4) · 6d2ddc2f
      John David Anglin 提交于
      Implement clear_page_asm and copy_page_asm. These are optimized routines to
      clear and copy a page.  I tested prefetch optimizations in clear_page_asm and
      copy_page_asm but didn't see any significant performance improvement on rp3440.
      I'm not sure if these are routines are significantly faster than memset and/or
      memcpy, but they are there for further performance evaluation.
      
      TLB purge operations on PA 1.X SMP machines are now serialized with the help of
      the new tlb_lock() and tlb_unlock() macros, since on some PA-RISC machines, TLB
      purges need to be serialized in software.  Obviously, lock isn't needed in UP
      kernels.  On PA 2.0 machines, there is a local TLB instruction which is much
      less disruptive to the memory subsystem.  No lock is needed for local purge.
      
      Loops are also unrolled in flush_instruction_cache_local and
      flush_data_cache_local.
      
      The implementation of what used to be copy_user_page (now copy_user_page_asm)
      is now fixed. Additionally 64-bit support is now added. Read the preceding
      comment which I didn't change.  I left the comment but it is now inaccurate.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      6d2ddc2f
  4. 16 5月, 2012 1 次提交
  5. 16 4月, 2011 1 次提交
  6. 15 1月, 2011 1 次提交
    • J
      parisc: flush pages through tmpalias space · f311847c
      James Bottomley 提交于
      The kernel has an 8M tmpailas space (originally designed for copying
      and clearing pages but now only used for clearing).  The idea is
      to place zeros into the cache above a physical page rather than into
      the physical page and flush the cache, because often the zeros end up
      being replaced quickly anyway.
      
      We can also use the tmpalias space for flushing a page.  The difference
      here is that we have to do tmpalias processing in the non access data and
      instruction traps.  The principle is the same: as long as we know the physical
      address and have a virtual address congruent to the real one, the flush will
      be effective.
      
      In order to use the tmpalias space, the icache miss path has to be enhanced to
      check for the alias region to make the fic instruction effective.
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      f311847c
  7. 13 6月, 2008 1 次提交
  8. 15 5月, 2008 2 次提交
  9. 18 10月, 2007 1 次提交
  10. 17 2月, 2007 2 次提交
  11. 01 7月, 2006 1 次提交
  12. 22 4月, 2006 1 次提交
  13. 31 3月, 2006 1 次提交
  14. 22 10月, 2005 5 次提交
  15. 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