From nir.geller at servotronix.com  Wed Jan 29 11:31:15 2020
From: nir.geller at servotronix.com (Geller, Nir)
Date: Wed, 29 Jan 2020 10:31:15 +0000
Subject: [etherlab-dev] wait_event() causes uninterruptible_sleep
Message-ID: <PR1PR07MB5867106056210B6ADE4EE0F190050@PR1PR07MB5867.eurprd07.prod.outlook.com>

Hi There,

we are working with etherlab's ethercat master and recently we've encountered a problem that is related to a non interruptible wait_event().

The scenario:
A multi-threaded user space app cyclically reads SDO from some ecat slave.
The user space app then crashes.
All the threads end besides the one that performs the SDO read:

.....
1022  1022 TS       -   0  19   0  0.0 Zl   task_dead                abcde <defunct>
1022  1202 RR       2   -  42   0  0.6 Dl   ecrt_master_sdo_upload   abcde1
.....

This situation interferes with debugging the app, and prevents a core dump from being generated.

In master.c in ecrt_master_sdo_upload() I see an invoke of wait_event_interruptible() followed by an invoke of wait_event().

After changing wait_event() to wait_event_interruptible() the app can successfully crash, and it is now easier to debug.

Needless to say, we need a core dump to be generated when the app crashes at costumer's site.

The question is what is the reason behind using wait_event() instead of wait_event_interruptible() ?

Is it safe for us to change the code?

Thanks,

Nir.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/406a569c/attachment.html>

From gavin.lambert at tomra.com  Wed Jan 29 23:50:57 2020
From: gavin.lambert at tomra.com (Gavin Lambert)
Date: Wed, 29 Jan 2020 22:50:57 +0000
Subject: [etherlab-dev] wait_event() causes uninterruptible_sleep
In-Reply-To: <PR1PR07MB5867106056210B6ADE4EE0F190050@PR1PR07MB5867.eurprd07.prod.outlook.com>
References: <PR1PR07MB5867106056210B6ADE4EE0F190050@PR1PR07MB5867.eurprd07.prod.outlook.com>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.5fd532f0-df31-45e5-85b2-addfa7c17799.f186524c-399d-45db-9f5a-f7a45508e863@emailsignatures365.codetwo.com>
Message-ID: <VE1PR03MB5677FEC68B1A220191685E2FE8050@VE1PR03MB5677.eurprd03.prod.outlook.com>

I'm not entirely sure, but I don't think simply changing that would be safe.

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.)

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.)


If you instead explicitly close(masterfd) (aka ecrt_release_master) in your problem case, this should abort all pending requests and wake up the threads - you can see the code that does this in ec_slave_clear and ec_master_clear_slaves.

(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.)

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.


Gavin Lambert
Senior Software Developer

[cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png]
[cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png]<http://www.compacsort.com> [cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png] <https://www.facebook.com/Compacsort>  [cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png] <https://www.linkedin.com/company/compac-sorting-equipment/>  [cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png] <https://vimeo.com/compacsort>  [cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png] <https://twitter.com/compacsort>  [cid:insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png] <https://www.instagram.com/compacsort/>

COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +64 96 34 00 88 | tomra.com<http://www.tomra.com>

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.

From: Geller, Nir
Sent: Wednesday, 29 January 2020 23:31
To: etherlab-dev at etherlab.org
Subject: [etherlab-dev] wait_event() causes uninterruptible_sleep

Hi There,

we are working with etherlab's ethercat master and recently we've encountered a problem that is related to a non interruptible wait_event().

The scenario:
A multi-threaded user space app cyclically reads SDO from some ecat slave.
The user space app then crashes.
All the threads end besides the one that performs the SDO read:

.....
1022  1022 TS       -   0  19   0  0.0 Zl   task_dead                abcde <defunct>
1022  1202 RR       2   -  42   0  0.6 Dl   ecrt_master_sdo_upload   abcde1
.....

This situation interferes with debugging the app, and prevents a core dump from being generated.

In master.c in ecrt_master_sdo_upload() I see an invoke of wait_event_interruptible() followed by an invoke of wait_event().

After changing wait_event() to wait_event_interruptible() the app can successfully crash, and it is now easier to debug.

Needless to say, we need a core dump to be generated when the app crashes at costumer's site.

The question is what is the reason behind using wait_event() instead of wait_event_interruptible() ?

Is it safe for us to change the code?

Thanks,

Nir.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
Type: image/png
Size: 11438 bytes
Desc: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
Type: image/png
Size: 1629 bytes
Desc: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
Type: image/png
Size: 1750 bytes
Desc: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
Type: image/png
Size: 1855 bytes
Desc: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
Type: image/png
Size: 1970 bytes
Desc: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
Type: image/png
Size: 20278 bytes
Desc: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
Type: image/png
Size: 1506 bytes
Desc: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200129/2fc39c62/attachment-0013.png>

From Martin.Steih at lachmann-rink.de  Mon Feb 24 14:10:04 2020
From: Martin.Steih at lachmann-rink.de (Steih, Martin)
Date: Mon, 24 Feb 2020 13:10:04 +0000
Subject: [etherlab-dev] Ethercat master module make fails
Message-ID: <5D335160593F7D46910495E0DC2D1E25181D9CDD@LRV2006.lrintranet.local>

Hello,

I am trying to make the ethercat master module as described in the documentation, but it failes compiling the examples/mini/mini.c. The compiler complains about an implicit function declaration (init_timer line 496) as well as an incompatible pointer type at the following line. I am using kernel version 4.19.xx with rt patch. Does someone has any suggestions?

i. A. Martin Steih
Entwicklung
________________________________

Lachmann & Rink GmbH
Hommeswiese 129
57258 Freudenberg

Telefon: +49 2734 2817 430
Telefax: +49 2734 2817 20
E-Mail: Martin.Steih at lachmann-rink.de<mailto:Martin.Steih at lachmann-rink.de>
Internet: https://www.lachmann-rink.de

Gesch?ftsf?hrer: Dipl.-Ing. Arjan Bijlard, Dipl.-Inf. Claudius Rink

Amtsgericht Siegen, HRB 2600
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200224/fdc2514d/attachment.html>

From gavin.lambert at tomra.com  Wed Feb 26 00:29:13 2020
From: gavin.lambert at tomra.com (Gavin Lambert)
Date: Tue, 25 Feb 2020 23:29:13 +0000
Subject: [etherlab-dev] Ethercat master module make fails
In-Reply-To: <5D335160593F7D46910495E0DC2D1E25181D9CDD@LRV2006.lrintranet.local>
References: <5D335160593F7D46910495E0DC2D1E25181D9CDD@LRV2006.lrintranet.local>
 <471f8226-0853-49c5-9daa-cf6c15ca0ea2.5fd532f0-df31-45e5-85b2-addfa7c17799.449a1246-8273-4c45-a120-73b1f2b65533@emailsignatures365.codetwo.com>
Message-ID: <VE1PR03MB567749F0FD729082791BA787E8ED0@VE1PR03MB5677.eurprd03.prod.outlook.com>

Note that the standard distribution of the Etherlab master does not support kernel 4.19.  You can either downgrade your kernel or try using the unofficial patchset, which includes some compatibility patches for 4.19.


Gavin Lambert
Senior Software Developer

[cid:logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png]
[cid:compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png]<http://www.compacsort.com> [cid:facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png] <https://www.facebook.com/Compacsort>  [cid:linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png] <https://www.linkedin.com/company/compac-sorting-equipment/>  [cid:youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png] <https://vimeo.com/compacsort>  [cid:twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png] <https://twitter.com/compacsort>  [cid:insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png] <https://www.instagram.com/compacsort/>

COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
Switchboard: +64 96 34 00 88 | tomra.com<http://www.tomra.com>

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.

From: Steih, Martin
Sent: Tuesday, 25 February 2020 02:10
To: etherlab-dev at etherlab.org
Subject: [etherlab-dev] Ethercat master module make fails

Hello,

I am trying to make the ethercat master module as described in the documentation, but it failes compiling the examples/mini/mini.c. The compiler complains about an implicit function declaration (init_timer line 496) as well as an incompatible pointer type at the following line. I am using kernel version 4.19.xx with rt patch. Does someone has any suggestions?

i. A. Martin Steih
Entwicklung
________________________________

Lachmann & Rink GmbH
Hommeswiese 129
57258 Freudenberg

Telefon: +49 2734 2817 430
Telefax: +49 2734 2817 20
E-Mail: Martin.Steih at lachmann-rink.de<mailto:Martin.Steih at lachmann-rink.de>
Internet: https://www.lachmann-rink.de<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lachmann-rink.de%2F&data=02%7C01%7Cgavin.lambert%40tomra.com%7Cfbce07489c1b4c3d3b8a08d7b92ae04f%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637181466107808753&sdata=RC0oUxKY34BccfzEWFjPe7vyMBxgcPwemMhnuuwrF2Y%3D&reserved=0>

Gesch?ftsf?hrer: Dipl.-Ing. Arjan Bijlard, Dipl.-Inf. Claudius Rink

Amtsgericht Siegen, HRB 2600
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
Type: image/png
Size: 11438 bytes
Desc: logo_compac_5dcf97ef-52f5-498c-8b9b-728410ddffaf.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
Type: image/png
Size: 1629 bytes
Desc: compacicon_82e8a8c7-154a-4a32-9720-a5badb6258e0.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
Type: image/png
Size: 1750 bytes
Desc: facebook_fa85b924-53b9-45cc-8162-0564f64ec3a3.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
Type: image/png
Size: 1855 bytes
Desc: linkedin_4ec016ad-84fa-443c-85a3-b9615a4ccef8.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
Type: image/png
Size: 1970 bytes
Desc: youtube_32142163-fc27-4aed-b14d-e8a377f98a6d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
Type: image/png
Size: 20278 bytes
Desc: twitter_d89338d8-98c8-4b65-9a9e-7b1333160b0d.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
Type: image/png
Size: 1506 bytes
Desc: insta2_1cd85de9-b3a2-4971-9904-52b2481a7c82.png
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200225/2d7cfbf8/attachment-0013.png>

From moritz.schappler at imes.uni-hannover.de  Mon Apr  6 10:21:26 2020
From: moritz.schappler at imes.uni-hannover.de (Moritz Schappler)
Date: Mon, 6 Apr 2020 10:21:26 +0200
Subject: [etherlab-dev] New EtherLab Patch for External Mode Support
Message-ID: <ac531129-c4fb-da4e-3e89-4a22bae6f80b@imes.uni-hannover.de>

Dear EtherLab community,

I would like to inform you about a new patch of the etherlab-code that I
just uploaded on GitHub:
https://github.com/SchapplM/etherlab-code-extmodepatch

The patch presents a simplified version of EtherLab using the external
mode of Matlab/Simulink. Brief summary:
>     This is a patched version of EtherLab with the purpose of a vast simplifi-
>     cation of the code and using the external mode in Simulink without losing
>     real-time capabilities. The performed changes are:
>     - remove syslog
>     - remove pdserv
>     - remove multitasking
>     - remove arguments
>     - adjusted overrun notification
>     - add external mode and change thread-concept
>         - main is running as a low-priority-thread
>             - executes time-consuming, undeterministic extmode functions
>         - simulink model runs in single-tasking-mode in an RT-priority thread
>     The advantage is a simplified control and iteration of a Simulink model, 
>     since no additional PdServ application has to be created.
The code was created by Lucas J?rgens in his Bachelor's Thesis at the
Institute for Automatic Control at the Leibniz University of Hannover,
Germany.

If you have any comments on the patch I would be happy to discuss them
with you.
I am especially interested if you think this is a useful extension or if
there are major issues in the principle, since we also use the code in
some realtime control testbeds.

Best regards,

Moritz Schappler

-- 
__________________________________________________________
M. Sc. Moritz Schappler
Wissenschaftlicher Mitarbeiter und Gruppenleiter
Robotik & autonome Systeme

Gottfried Wilhelm Leibniz Universit?t Hannover
Institut f?r Mechatronische Systeme
An der Universit?t 1, Geb?ude 8142 (Etage 1, Raum 108)
30823 Garbsen

Fon: +49 (0)511 762-4116
Fax: +49 (0)511 762-19976

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200406/12a6ce65/attachment.html>

From kba at deif.com  Tue May 26 13:33:47 2020
From: kba at deif.com (Knud Baastrup)
Date: Tue, 26 May 2020 11:33:47 +0000
Subject: [etherlab-dev] pdo_read and pdo_write commands for EtherCAT tool
	patch
Message-ID: <c1d41b1f86b34ecf82dd256fc8580ba8@deif.com>

Hi

I have attached a patch that allow the EtherCAT tool to read and write domain data using pdo_read and pdo_write commands. The commands use index and subindex for a given PDO entry as argument. The commands are useful for test scripts and debugging.

The patch should apply clean on top of the Etherlab master patchset 20190904 maintained by Gavin Lambert.


Best regards

Knud Baastrup

Software Designer
R&D Platform Software
DEIF A/S
Email:

 kba at deif.com<mailto:kba at deif.com>

Tel.:

 +45 9614 8458<tel:+45%209614%208458>


[cid:image001.jpg at 01D63362.487B9AC0]<https://www.deif.com/>

deif.com<https://www.deif.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200526/2acb17ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1118 bytes
Desc: image001.jpg
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200526/2acb17ed/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-pdo_read-and-pdo_write-commands-to-EtherCAT-tool.patch
Type: application/octet-stream
Size: 28790 bytes
Desc: 0001-Add-pdo_read-and-pdo_write-commands-to-EtherCAT-tool.patch
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20200526/2acb17ed/attachment-0001.obj>