1. 14 11月, 2009 1 次提交
  2. 02 11月, 2009 1 次提交
    • K
      MIPS: Fix machine check exception in kmap_coherent() · 0f334a3e
      Kevin Cernekee 提交于
      On an SMP system with cache aliases, the following sequence of events may
      happen:
      
      1) copy_user_highpage() runs on CPU0, invoking kmap_coherent() to create a
         temporary mapping in the fixmap region
      2) copy_page() starts on CPU0
      3) CPU1 sends CPU0 an IPI asking CPU0 to run local_r4k_flush_cache_page()
      4) CPU0 takes the interrupt, interrupting copy_page()
      5) local_r4k_flush_cache_page() on CPU0 calls kmap_coherent() again
      6) The second invocation of kmap_coherent() on CPU0 tries to use the
         same fixmap virtual address that was being used by copy_user_highpage()
      7) CPU0 throws a machine check exception for the TLB address conflict
      
      Fixed by creating an extra set of fixmap entries for use in interrupt
      handlers.  This prevents fixmap VA conflicts between copy_user_highpage()
      running in user context, and local_r4k_flush_cache_page() invoked from an
      SMP IPI.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0f334a3e
  3. 01 10月, 2009 1 次提交
  4. 24 9月, 2009 1 次提交
  5. 23 9月, 2009 3 次提交
  6. 22 9月, 2009 1 次提交
  7. 18 9月, 2009 4 次提交
  8. 04 8月, 2009 3 次提交
  9. 13 7月, 2009 1 次提交
  10. 25 6月, 2009 1 次提交
  11. 22 6月, 2009 1 次提交
  12. 17 6月, 2009 10 次提交
  13. 21 5月, 2009 1 次提交
    • G
      MIPS: 64-bit: Fix system lockup. · a5e696e5
      Greg Ungerer 提交于
      The address range size calculation inside local_flush_tlb_kernel_range()
      is being truncated by a too small size variable holder on 64-bit systems.
      The truncated size can result in an erroneous tlbsize check that means we
      sit spinning inside a loop trying to flush a hige number of TLB entries.
      This is for all intents and purposes a system hang. Fix by using an
      appropriately sized valiable to hold the size.
      
      [Ralf: Greg's original patch submission identified the issue and fixed one
      instance in tlb-r4k.c but there there were several more.  For consistency
      I also modified tlb-r3k.c even though that file is only used on 32-bit.]
      Signed-off-by: NGreg Ungerer <gerg@snapgear.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a5e696e5
  14. 14 5月, 2009 4 次提交
  15. 01 4月, 2009 1 次提交
  16. 30 3月, 2009 3 次提交
  17. 24 3月, 2009 2 次提交
  18. 12 3月, 2009 1 次提交
    • S
      MIPS: NEC VR5500 processor support fixup · a644b277
      Shinya Kuribayashi 提交于
      Current VR5500 processor support lacks of some functions which are
      expected to be configured/synthesized on arch initialization.
      
      Here're some VR5500A spec notes:
      
      * All execution hazards are handled in hardware.
      
      * Once VR5500A stops the operation of the pipeline by WAIT instruction,
        it could return from the standby mode only when either a reset, NMI
        request, or all enabled interrupts is/are detected.  In other words,
        if interrupts are disabled by Status.IE=0, it keeps in standby mode
        even when interrupts are internally asserted.
      
        Notes on WAIT: The operation of the processor is undefined if WAIT
        insn is in the branch delay slot.  The operation is also undefined
        if WAIT insn is executed when Status.EXL and Status.ERL are set to 1.
      
      * VR5500A core only implements the Load prefetch.
      
      With these changes, it boots fine.
      Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a644b277