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 [1], 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 [2]. 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. -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
