1. 08 5月, 2013 1 次提交
    • H
      MIPS: Build uasm-generated code only once to avoid CPU Hotplug problem · 8759934e
      Huacai Chen 提交于
      This and the next patch resolve memory corruption problems while CPU
      hotplug. Without these patches, memory corruption can triggered easily
      as below:
      
      On a quad-core MIPS platform, use "spawn" of UnixBench-5.1.3 (http://
      code.google.com/p/byte-unixbench/) and a CPU hotplug script like this
      (hotplug.sh):
      while true; do
      echo 0 >/sys/devices/system/cpu/cpu1/online
      echo 0 >/sys/devices/system/cpu/cpu2/online
      echo 0 >/sys/devices/system/cpu/cpu3/online
      sleep 1
      echo 1 >/sys/devices/system/cpu/cpu1/online
      echo 1 >/sys/devices/system/cpu/cpu2/online
      echo 1 >/sys/devices/system/cpu/cpu3/online
      sleep 1
      done
      
      Run "hotplug.sh" and then run "spawn 10000", spawn will get segfault
      after a few minutes.
      
      This patch:
      Currently, clear_page()/copy_page() are generated by Micro-assembler
      dynamically. But they are unavailable until uasm_resolve_relocs() has
      finished because jump labels are illegal before that. Since these
      functions are shared by every CPU, we only call build_clear_page()/
      build_copy_page() only once at boot time. Without this patch, programs
      will get random memory corruption (segmentation fault, bus error, etc.)
      while CPU Hotplug (e.g. one CPU is using clear_page() while another is
      generating it in cpu_cache_init()).
      
      For similar reasons we modify build_tlb_refill_handler()'s invocation.
      
      V2:
      1, Rework the code to make CPU#0 can be online/offline.
      2, Introduce cpu_has_local_ebase feature since some types of MIPS CPU
         need a per-CPU tlb_refill_handler().
      Signed-off-by: NHuacai Chen <chenhc@lemote.com>
      Signed-off-by: NHongbing Hu <huhb@lemote.com>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Patchwork: http://patchwork.linux-mips.org/patch/4994/Acked-by: NJohn Crispin <blogic@openwrt.org>
      8759934e
  2. 19 2月, 2013 1 次提交
  3. 17 2月, 2013 1 次提交
  4. 16 2月, 2013 1 次提交
    • S
      MIPS: Add printing of ISA version in cpuinfo. · a96102be
      Steven J. Hill 提交于
      Display the MIPS ISA version release in the /proc/cpuinfo file.
      
      [ralf@linux-mips.org: Add support for MIPS I ... IV legacy architecture
      revisions.  Also differenciate between MIPS32 and MIPS64 versions instead
      of lumping them together as just r1 and r2.
      
      Note to application programmers: this indicates the CPU's ISA level
      It does not imply the current execution environment does support it.  For
      example an O32 application seeing "mips64r2" would still be restricted by
      by the execution environment to 32-bit - but the kernel could run mips64r2
      code.  The same for a 32-bit kernel running on a 64-bit processor.  This
      field doesn't include ASEs or optional architecture modules nor other
      detailed flags such as the availability of an FPU.]
      Signed-off-by: NSteven J. Hill <sjhill@mips.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: http://patchwork.linux-mips.org/patch/4714/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a96102be
  5. 01 2月, 2013 1 次提交
  6. 11 10月, 2012 2 次提交
  7. 14 9月, 2012 2 次提交
  8. 05 8月, 2010 1 次提交
  9. 27 2月, 2010 1 次提交
    • D
      MIPS: Implement Read Inhibit/eXecute Inhibit · 6dd9344c
      David Daney 提交于
      The SmartMIPS ASE specifies how Read Inhibit (RI) and eXecute Inhibit
      (XI) bits in the page tables work.  The upper two bits of EntryLo{0,1}
      are RI and XI when the feature is enabled in the PageGrain register.
      SmartMIPS only covers 32-bit systems.  Cavium Octeon+ extends this to
      64-bit systems by continuing to place the RI and XI bits in the top of
      EntryLo even when EntryLo is 64-bits wide.
      
      Because we need to carry the RI and XI bits in the PTE, the layout of
      the PTE is changed.  There is a two instruction overhead in the TLB
      refill hot path to get the EntryLo bits into the proper position.
      Also the TLB load exception has to probe the TLB to check if RI or XI
      caused the exception.
      
      Also of note is that the layout of the PTE bits is done at compile and
      runtime rather than statically.  In the 32-bit case this allows for
      the same number of PFN bits as before the patch as the _PAGE_HUGE is
      not supported in 32-bit kernels (we have _PAGE_NO_EXEC and
      _PAGE_NO_READ instead of _PAGE_READ and _PAGE_HUGE).
      
      The patch is tested on Cavium Octeon+, but should also work on 32-bit
      systems with the Smart-MIPS ASE.
      Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
      To: linux-mips@linux-mips.org
      Patchwork: http://patchwork.linux-mips.org/patch/952/
      Patchwork: http://patchwork.linux-mips.org/patch/956/
      Patchwork: http://patchwork.linux-mips.org/patch/962/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      6dd9344c
  10. 03 2月, 2010 1 次提交
  11. 18 9月, 2009 1 次提交
  12. 17 6月, 2009 2 次提交
  13. 14 5月, 2009 1 次提交
  14. 11 1月, 2009 1 次提交
  15. 30 10月, 2008 1 次提交
  16. 11 10月, 2008 1 次提交
  17. 01 12月, 2007 1 次提交
    • P
      [MIPS] Fix use of smp_processor_id() in preemptible code. · 54fd6441
      Pavel Kiryukhin 提交于
      Freeing prom memory: 956kb freed
      Freeing firmware memory: 978944k freed
      Freeing unused kernel memory: 180k freed
      BUG: using smp_processor_id() in preemptible [00000000] code: swapper/1
      caller is r4k_dma_cache_wback_inv+0x144/0x2a0
      Call Trace:
       [<80117af8>] r4k_dma_cache_wback_inv+0x144/0x2a0
       [<802e4b84>] debug_smp_processor_id+0xd4/0xf0
       [<802e4b7c>] debug_smp_processor_id+0xcc/0xf0
      ...
      CONFIG_DEBUG_PREEMPT is enabled.
      --
      Bug cause is blast_dcache_range() in preemptible code [in
      r4k_dma_cache_wback_inv()].
      blast_dcache_range() is constructed via __BUILD_BLAST_CACHE_RANGE that
      uses cpu_dcache_line_size(). It uses current_cpu_data that use
      smp_processor_id() in turn. In case of CONFIG_DEBUG_PREEMPT
      smp_processor_id emits BUG if we are executing with preemption
      enabled.
      
      Cpu options of cpu0 are assumed to be the superset of all processors.
      
      Can I make the same assumptions for cache line size  and fix this
      issue the following way:
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      54fd6441
  18. 12 10月, 2007 2 次提交
  19. 11 7月, 2007 1 次提交
  20. 17 3月, 2007 1 次提交
  21. 14 7月, 2006 2 次提交
  22. 30 6月, 2006 1 次提交
  23. 26 4月, 2006 1 次提交
  24. 19 4月, 2006 1 次提交
  25. 19 3月, 2006 1 次提交
  26. 10 1月, 2006 2 次提交
  27. 30 10月, 2005 5 次提交
  28. 05 9月, 2005 1 次提交
  29. 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