<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Dear all, </div><div><br></div><div>The bug has been fixed. It was only occurring when rtspin was called in "verbose" mode. Suspension of tasks was occurring due to the prints contained in the rtspin code (including some prints added by me). Now there are no more zombie tasks, I just need to investigate why after running the tasks the system is not allowing to change the plugin.</div><div><br></div><div>Thanks for the help.</div><div><br></div><div>Regards,</div><div><br></div><div>Ricardo</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Em dom, 23 de dez de 2018 às 09:00, <<a href="mailto:litmus-dev-request@lists.litmus-rt.org">litmus-dev-request@lists.litmus-rt.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send litmus-dev mailing list submissions to<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" rel="noreferrer" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:litmus-dev-request@lists.litmus-rt.org" target="_blank">litmus-dev-request@lists.litmus-rt.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:litmus-dev-owner@lists.litmus-rt.org" target="_blank">litmus-dev-owner@lists.litmus-rt.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of litmus-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: litmus-dev Digest, Vol 79, Issue 4 (Ricardo Teixeira)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 22 Dec 2018 10:41:18 -0300<br>
From: Ricardo Teixeira <<a href="mailto:ricardo.btxr@gmail.com" target="_blank">ricardo.btxr@gmail.com</a>><br>
To: <a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
Subject: Re: [LITMUS^RT] litmus-dev Digest, Vol 79, Issue 4<br>
Message-ID:<br>
<<a href="mailto:CADjj2cFs-B_bVyZJQwkNdR1L1KrwKaJaBPgjBR9%2Bfefw4nCUtA@mail.gmail.com" target="_blank">CADjj2cFs-B_bVyZJQwkNdR1L1KrwKaJaBPgjBR9+fefw4nCUtA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Björn, thanks again.<br>
<br>
The bug was partially fixed. An instruction was missing to verify if the<br>
task was blocked, before the call to requeue(), inside schedule(). After<br>
that some tasks remained zombies, yet. Now I'm putting more TRACE_TASK()<br>
calls to better understand the behavior.<br>
<br>
I noticed that after a task be suspended, it does not execute anymore. I'll<br>
try the next_became_invalid() callback, as suggested.<br>
<br>
Regards,<br>
<br>
Ricardo<br>
<br>
Em sáb, 22 de dez de 2018 às 08:01, <<a href="mailto:litmus-dev-request@lists.litmus-rt.org" target="_blank">litmus-dev-request@lists.litmus-rt.org</a>><br>
escreveu:<br>
<br>
> Send litmus-dev mailing list submissions to<br>
> <a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
><br>
> To subscribe or unsubscribe via the World Wide Web, visit<br>
> <a href="https://lists.litmus-rt.org/listinfo/litmus-dev" rel="noreferrer" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
> or, via email, send a message with subject or body 'help' to<br>
> <a href="mailto:litmus-dev-request@lists.litmus-rt.org" target="_blank">litmus-dev-request@lists.litmus-rt.org</a><br>
><br>
> You can reach the person managing the list at<br>
> <a href="mailto:litmus-dev-owner@lists.litmus-rt.org" target="_blank">litmus-dev-owner@lists.litmus-rt.org</a><br>
><br>
> When replying, please edit your Subject line so it is more specific<br>
> than "Re: Contents of litmus-dev digest..."<br>
><br>
><br>
> Today's Topics:<br>
><br>
> 1. Re: litmus-dev Digest, Vol 79, Issue 2 (Björn Brandenburg)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Fri, 21 Dec 2018 12:58:06 +0100<br>
> From: Björn Brandenburg <<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>><br>
> To: <a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
> Subject: Re: [LITMUS^RT] litmus-dev Digest, Vol 79, Issue 2<br>
> Message-ID: <<a href="mailto:F48ECE7B-4375-4703-932E-CE487E500F3D@mpi-sws.org" target="_blank">F48ECE7B-4375-4703-932E-CE487E500F3D@mpi-sws.org</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> On 21. Dec 2018, at 03:24, Ricardo Teixeira <<a href="mailto:ricardo.btxr@gmail.com" target="_blank">ricardo.btxr@gmail.com</a>><br>
> wrote:<br>
> ><br>
> > I am implementing a protocol based on MrsP, which involves the migration<br>
> of tasks, but the protocol does not contemplate the suspension of tasks. I<br>
> have not tried to reproduce this for the stock plugins. The plugin I'm<br>
> using was implemented by a colleague, it also involves the migration of<br>
> tasks.<br>
><br>
> Sorry, not much I can say in that case. Migrations are tricky. There are<br>
> many ways in which a race condition might arise such that LITMUS^RT’s<br>
> migration sanity checker is triggered (which is the code you pointed to).<br>
><br>
> Basically, the code that triggered observes that the ‘next’ task, which<br>
> was picked by the plugin to be dispatched next, and which needs to be<br>
> pulled from another core’s runqueue, somehow changed state while the<br>
> migration path dropped the remote core’s runqueue lock. Maybe it<br>
> self-suspended due to blocking I/O, maybe it received a signal, maybe it<br>
> hit a page fault, maybe it tried calling a library function not yet<br>
> resolved by the dynamic linker thus triggering a page fault, maybe<br>
> something else?<br>
><br>
> In all likelihood, this is a fatal bug in the scheduler or locking<br>
> protocol, and you should just fix the bug. However, for edge cases,<br>
> LITMUS^RT provides the next_became_invalid() callback in the plugin API,<br>
> which allows you to do something more clever than just dropping all<br>
> references to the task (which causes it to become an unkillable “zombie”<br>
> task). That said, I would strongly urge you to not just work around the<br>
> problem using next_became_invalid() unless you fully understand the root<br>
> cause and realize that it’s a fundamental limitation and not just a simple<br>
> bug.<br>
><br>
> My approach to debugging a problem like this would be to simply<br>
> “carpet-bomb” the scheduler plugin and locking protocol implementations<br>
> with TRACE_TASK() and stare at debug traces until I understand exactly what<br>
> sequence of events leads to the sanity checker triggering. Of course, with<br>
> a sufficient number of TRACE_TASK() instances, you might just change the<br>
> timing enough to hide the race, which would make it quite a bit harder to<br>
> debug. Good luck. :-)<br>
><br>
> Generally, protocols like the MrsP are very difficult to implement<br>
> correctly precisely because it’s tricky to get the migrations right. This<br>
> also applies to varying degrees to the MBWI, OMIP, and MC-IPC protocols.<br>
> Just my 2 cents…<br>
><br>
> - Björn<br>
><br>
> -------------- next part --------------<br>
> A non-text attachment was scrubbed...<br>
> Name: smime.p7s<br>
> Type: application/pkcs7-signature<br>
> Size: 5041 bytes<br>
> Desc: not available<br>
> URL: <<br>
> <a href="http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20181221/b76ba27a/attachment-0001.bin" rel="noreferrer" target="_blank">http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20181221/b76ba27a/attachment-0001.bin</a><br>
> ><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
><br>
> _______________________________________________<br>
> litmus-dev mailing list<br>
> <a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
> <a href="https://lists.litmus-rt.org/listinfo/litmus-dev" rel="noreferrer" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> End of litmus-dev Digest, Vol 79, Issue 4<br>
> *****************************************<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20181222/c67d2f3e/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20181222/c67d2f3e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org" target="_blank">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" rel="noreferrer" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of litmus-dev Digest, Vol 79, Issue 5<br>
*****************************************<br>
</blockquote></div>