Re: [Xenomai-help] Priority coupling broken?

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

Henri Roosen wrote:
> Did some more tracing to see why the lower priority thread is
> scheduled before the higher prio thread is ended.
> 
> The highest priority task makes a system call and gets relaxed by
> xnshadow_relax. The rpi is pushed here and a Linux call with
> LO_WAKEUP_REQ is scheduled. Then I see the scheduler scheduling to the
> ROOT task. So far so good!
> 
> In the Linux domain, we run into the lostage_handler, where the
> scheduled LO_WAKEUP_REQ is executed. Here there is a call to
> xnpod_schedule() which actually causes a switch back to the primary
> domain and the lower priority Xenomai task to be scheduled in, even
> before the wanted process is woken up.
>
> Now, I am unsure what is faulty here and maybe Philippe or someone can
> answer that. Personally I would have expected the xnpod_schedule (or
> xnsched_pick_next) to know about the rpi list and not schedule a lower
> priority task than of any on that list. I was unable to find such
> code.
>

Unless I am wrong, what happens is whait is intended, at least if we
read the comment:
		case LO_WAKEUP_REQ:
			/*
			 * We need to downgrade the root thread
			 * priority whenever the APC runs over a
			 * non-shadow, so that the temporary boost we
			 * applied in xnshadow_relax() is not
			 * spuriously inherited by the latter until
			 * the relaxed shadow actually resumes in
			 * secondary mode.
			 */
			rpi_clear_local(xnshadow_thread(current));
			xnpod_schedule();

Which means that we do not want other Linux kernel code than the
real-time thread itself to inherit from this thread priority. Except
that all the code from the switch to root thread to the lostage_handler
(which means any Linux currently preempted critical section) already
inherited the priority.

-- 
					    Gilles.