Re: Cyclictest results on Sparc64 with PREEMPT_RT

[Kirill Tkhai <tkhai@yandex.ru>]

07.02.2014, 17:31, "Allen Pais" <allen.pais@oracle.com>:
> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html