On Thu, 2007-07-19 at 14:40 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> >> And when looking at the holders of rpilock, I think one issue could be
> >> that we hold that lock while calling into xnpod_renice_root , ie.
> >> doing a potential context switch. Was this checked to be save?
> > xnpod_renice_root() does no reschedule immediately on purpose, we would
> > never have been able to run any SMP config more than a couple of seconds
> > otherwise. (See the NOSWITCH bit).
> OK, then it's not the cause.
> >> Furthermore, that code path reveals that we take nklock nested into
> >> rpilock . I haven't found a spot for the other way around (and I hope
> >> there is none)
> > xnshadow_start().
> Nope, that one is not holding nklock. But I found an offender...
Gasp. xnshadow_renice() kills us too.
Xenomai-core mailing list