On 03/27/2013 11:35 AM, Jan Kiszka wrote:
On 2013-03-27 11:32, Philippe Gerum wrote:
On 03/27/2013 11:27 AM, Jan Kiszka wrote:
Nitpicking: in theory, the code should expect the migration hook to have
actually done the work, and not delayed it like Xenomai currently does
in practice.
Where does Xenomai do that? I was looking for it but didn't find a log
flush.
You mean delaying? Check per-arch xnarch_escalate(). Flushing occurs as
soon as the xnpod_schedule() caller unstalls the head domain, which has
to happen quickly after the delay was enforced.
Hmm, I still do not see where we should flush in Xenomai forge before
the return to complete_domain_migration and its clearance of the stall flag.
With the new migration interface, we don't have to do that from Xenomai,
since the migration hook assumes it is called with the head domain
stalled, so the caller has to unstall shortly after anyway. But for that
to work, we need your latest fix.
2.x was immune because everything happened on behalf of the gatekeeper,
which triggered a rescheduling with head unstalled. This is how the bug
slipped into the -forge logic.
--
Philippe.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
