07.02.2014, 17:31, "Allen Pais" <allen.pais@xxxxxxxxxx>: > Sebastian, > >> This is a dead lock. Whatever lock you go after, you are already >> holding it in this context / hackbench. I don't know how you got from >> perfctr_irq() to do_exit() but you shouldn't do this in hardirq >> context. >> >> But calling do_exit() is probably error recovery since it would kill >> hackbench and I assume it wasn't done yet. >> I see also tl0_irq15() in your stack trace. This is that evil NMI that >> checks if the system is stalling. I think that you stuck in >> flush_tsb_user() on that raw_lock and somebody is not letting it go and >> so you spin for ever. Maybe full lockdep shows you some informations >> about wrong context locking etc. > > Yes, there's someone's holding the lock and not releasing it in > flush_tsb_user(). I'll check with lockdep. I'm looking at arch_enter_lazy_mmu_mode()/arch_leave_lazy_mmu_mode(). It looks like it's assumed they are called with preemption disabled. In !RT case they are called after spin_lock() which gives preemption disabled. In RT the spinlocks are mutexes and there is preemption. I think we need something like migrate_disable() here. I have no sparc right now and did not check this carefully. Check if you are interested :) Kirill > Thanks, > Allen > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
