Re: [Xenomai] Sleeping function called from invalid context

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Thu, Dec 11, 2014 at 04:31:38PM +0000, Stoidner, Christoph wrote:
> >> > Ok, maybe we have some hope with the tracer though. What should
> >> > trigger a trace is the fact that a relax request has been sent, but
> >> > that the next linux scheduling point does not wake up the said task.
> >> > This is all debug code, so it does not need to be clean. You can
> >> > define a per-cpu variable (if running on SMP systems, otherwise a
> >> > global variable will do) with the last request posted. And when a
> >> > linux scheduling happens, test that the newly scheduled task is the
> >> > task that was passed to the relax, if that is not the case, trigger
> >> > a trace freeze. The point where the nucleus is informed of a Linux
> >> > task switch is do_schedule_event(). The trick is that if you have
> >> > some tasks with a higher priority than the relaxed task, it is
> >> > normal that the relaxed task is not scheduled immediately, so if you
> >> > want the condition to hold, you need to run the xenomai tasks which
> >> > relax with the highest priority. Also, obviously, after the test,
> >> > the pointer should be reset to NULL, because there are several task
> >> > queued, and with a global variable you have no way of knowing which
> >> > is next.
> >>
> >> I will do so. Do I have to change the gatekeeper's priority behind the relaxing
> >> task to assure that the gatekeeper would be scheduled before?
> >
> > The gatekeeper is not involved.
> 
> Sorry, I wanted to say: "that gatekeeper would NOT be scheduled before?". Otherwise
> we see possibly the gatekeeper instead of the relaxed task? Or am I wrong?

I meant to say the gatekeeper is not involved in the primary to
secondary mode switches, only in the secondary to primary mode
switches. But yes, since it runs with the highest priority, it may
be the one scheduled when back to primary mode. Though I would say
it is probably very unlikely, since the events activating the
gatekeeper is a secondary mode event, which by definition could not
have happened while another task was in primary mode. So what could
happen is that one task running in secondary mode tries to switch to
primary mode, at which point, before the gatekeeper is even
activated, another task running in primary mode is activated
(perhaps because it is waiting for an interrupt, may it be atimer).

-- 
					    Gilles.