<div dir="ltr"><div>I have already looked into that, but as you suggested every function has its context and I suppose that there are a lot of differences among the schedul_plugin and the litmus_lock_ops callbacks.</div><div>

<br></div><div>I probably need to release the lock on the local cpu before calling the migration function.</div><div><br></div><div>Another thing that isn't unclear to me is why the error generated by the task set is raised by the cpu 0, which should not be affected by any migration, instead of cpu 1 or 2.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/13 Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
On 13 Jan 2014, at 20:10, Sebastiano Catellani <<a href="mailto:zebganzo@gmail.com">zebganzo@gmail.com</a>> wrote:<br>
<br>
> First of all thanks for the answer, I know that It isn't correct to make a task migrate from a cpu to another in a partitioned system, but It's a prototype for a more complex scheduler that allows a task to migrate only when particular conditions are met.<br>


<br>
</div>Ah, ok, I see.<br>
<div class="im"><br>
><br>
> I understand my mistake, I will look under the hood hoping to find out how to avoid deadlock by calling the migrate_to function.<br>
<br>
</div>Have a look at how pfp_migrate_to() is used by the DPCP implementation (for which it was introduced).<br>
<div class="HOEnZb"><div class="h5"><br>
Regards,<br>
Björn<br>
<br>
<br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</div></div></blockquote></div><br></div>