On Tue, Nov 27, 2007 at 07:20:47PM +0300, Pavel Kiryukhin wrote: > I get the following bug running 2.6.18 on malta34Kc . > > 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: That's safe and probably saner than littlering preempt_disable / preempt_enable calls over the code. Ralf
