1. 01 12月, 2007 2 次提交
    • R
      [MIPS] Fix build. · e6a1bb72
      Ralf Baechle 提交于
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e6a1bb72
    • 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
  2. 30 11月, 2007 38 次提交