<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">I’m not entirely sure, but I don’t think simply changing that would be safe.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The whole “on interrupt return -EINTR” thing assumes that it’s safe to simply make the exact same call again to “resume” the operation. This is true in the first case because it’s just waiting for the request to be enqueued, and on interrupt
it simply dequeues it again. However after that there’s a race where it might have already been sent and is waiting for a response, and in that case it’s not safe to return -EINTR because it might end up being sent a second time, which could cause incorrect
behavior of the slave. (And would probably also confuse the mailbox FSM.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It might be possible to abort the request on interrupt instead, but that would be annoying as thread signals can cause spurious interrupts. (And might still end up meaning the slave will receive requests twice, if the app then explicitly
retries.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If you instead explicitly <span style="font-size:10.0pt;font-family:Consolas">
close(masterfd)</span> (aka <span style="font-size:9.5pt;font-family:Consolas;color:black">
ecrt_release_master</span>) in your problem case, this should abort all pending requests and wake up the threads – you can see the code that does this in
<span style="font-size:10.0pt;font-family:Consolas;color:black">ec_slave_clear</span> and
<span style="font-size:10.0pt;font-family:Consolas;color:black">ec_master_clear_slaves</span>.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(The OS will automatically do this when your process actually terminates, but not while you still have a live thread. So you will have to use an exception/signal handler to intercept the crash in progress.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Another option is to use the non-blocking SDO request APIs instead. Using these (on the cyclic thread) is better anyway for regular transfers done while the master is activated, as it avoids ping-ponging the master locks between multiple
threads, which can increase cycle latency.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<P
style="FONT-SIZE: 100%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"><STRONG>Gavin Lambert<BR></STRONG>Senior Software Developer<BR></P>
<P style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">
<TABLE>
<TBODY
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"> </TBODY></TABLE></P>
<P style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><IMG border=0
src="cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png"><BR><A
href="http://www.compacsort.com"><IMG border=0 alt=TOMRA
src="cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png" width=33
height=37></A> <A href="https://www.facebook.com/Compacsort"><IMG border=0
alt=Facebook src="cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png" width=35
height=37></A> <A
href="https://www.linkedin.com/company/compac-sorting-equipment/"><IMG border=0
alt=Linkedin src="cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png" width=35
height=37></A> <A href="https://vimeo.com/compacsort"><IMG border=0 alt=Youtube
src="cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png" width=37 height=37></A>
<A href="https://twitter.com/compacsort"><IMG border=0 alt=twitter
src="cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png" width=33 height=37></A>
<A href="https://www.instagram.com/compacsort/"><IMG border=0 alt=instagram
src="cid:insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png" width=33 height=37></A>
</P>
<P
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"><B>COMPAC
SORTING EQUIPMENT LTD</B> | 4 Henderson Pl | Onehunga | Auckland 1061 | New
Zealand<BR>Switchboard: +64 96 34 00 88 | <A
href="http://www.tomra.com">tomra.com</A> </P>
<TABLE
style="BORDER-TOP-STYLE: none; BORDER-LEFT-STYLE: none; BORDER-COLLAPSE: collapse; BORDER-BOTTOM-STYLE: none; BORDER-RIGHT-STYLE: none"
cellSpacing=0 cellPadding=0 border=1>
<TBODY>
<TR>
<TD
style="BORDER-LEFT-STYLE: none; BORDER-TOP: #595959 1pt solid; BORDER-BOTTOM: #595959 1pt solid; BORDER-RIGHT-STYLE: none"
vAlign=top>
<P
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)">The
information contained in this communication and any attachment is
confidential and may be legally privileged. It should only be read by the
person(s) to whom it is addressed. If you have received this communication
in error, please notify the sender and delete the communication.
</P></TD></TR></TBODY></TABLE>
<P
style="FONT-SIZE: 75%; FONT-FAMILY: Calibri, Candara, Segoe, Optima, Arial, sans-serif; COLOR: rgb(89,89,89)"></P><div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Geller, Nir<br>
<b>Sent:</b> Wednesday, 29 January 2020 23:31<br>
<b>To:</b> etherlab-dev@etherlab.org<br>
<b>Subject:</b> [etherlab-dev] wait_event() causes uninterruptible_sleep<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi There,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">we are working with etherlab's ethercat master and recently we've encountered a problem that is related to a non interruptible wait_event().<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The scenario:<o:p></o:p></p>
<p class="MsoNormal">A multi-threaded user space app cyclically reads SDO from some ecat slave.<o:p></o:p></p>
<p class="MsoNormal">The user space app then crashes.<o:p></o:p></p>
<p class="MsoNormal">All the threads end besides the one that performs the SDO read:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">.....<o:p></o:p></p>
<p class="MsoNormal">1022 1022 TS - 0 19 0 0.0 Zl task_dead abcde <defunct><o:p></o:p></p>
<p class="MsoNormal">1022 1202 RR 2 - 42 0 0.6 Dl ecrt_master_sdo_upload abcde1<o:p></o:p></p>
<p class="MsoNormal">.....<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This situation interferes with debugging the app, and prevents a core dump from being generated.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In master.c in ecrt_master_sdo_upload() I see an invoke of wait_event_interruptible() followed by an invoke of wait_event().<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">After changing wait_event() to wait_event_interruptible() the app can successfully crash, and it is now easier to debug.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Needless to say, we need a core dump to be generated when the app crashes at costumer's site.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The question is what is the reason behind using wait_event() instead of wait_event_interruptible() ?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Is it safe for us to change the code?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nir.<o:p></o:p></p>
</div>
</body>
</html>