On Thu, Dec 11, 2014 at 10:18:55AM +0000, Stoidner, Christoph wrote:
> >>
> >> >> > That is strange, are these tasks
> >> >> > running with the SCHED_OTHER policy ?
> >> >> No, they are running with sched fifo.
> >> >
> >> >Ok, next, are they using
> >> >rt_timer_mode_set
> >> >or
> >> >RT drivers which return -ENOSYS in their rt handlers ?
> >>
> >> Assumedly you mean rt_timer_set_mode() instead of rt_timer_mode_set().
> >> This function is not called since we are >using our own skin. Also our own
> >> skin does not use xntbase_switch(). Maybe it is interesting to know that
> >> our skin is >configured with periodic timing (1ms).
> >>
> >> RT drivers are also not installed on our system.
> >
> > Maybe I look wrong at nucleus/shadow.c, but I see only two reasons
> > for for xnshadow_relax being called for a secondary mode syscall:
> >
> > - a call requiring primary mode was made and the switchback flag is
> > set (which itself can have two reasons, either the fact that the
> > syscall uses it, the only one being currently rt_timer_set_mode, or
> > the fact that the caller runs with the SCHED_OTHER policy and does
> > not hold a mutex)
> >
> > - a call with the adaptive flag was made, handled in primary mode,
> > but returned -ENOSYS, which means the call needs to be retried in
> > secondary mode.
> >
>
> You are right. We have implemented some syscalls the require primary mode
> (since they could block) but should switch back to secondary. These syscalls
> are using attributes
>
> __xn_exec_primary | __xn_exec_switchback
Well then the tasks blocked with a stack trace like what you showed
are blocked when coming back from such syscalls. Does this happen
often, or are these syscall seldom used?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
