Hi all,
I've just updated the unofficial patchset to version 20190904. It is still based on the same upstream default commit as before: 33b922. https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme CAUTION regarding e1000e: * I've observed an issue when using motherboard-based e1000e on systems with an Intel MEI under recent versions of Linux 4.4 and above. (For example, 4.9.127+) * The problem manifests as communication initially working, but then permanently timing out after losing and regaining link. * Replugging the cable does not recover, but restarting the EtherCAT service does. * It only affects the ec_e1000e driver, not the ec_generic driver. * It does not affect e1000e add-in cards (or extra ports added by the motherboard manufacturer which are not under the control of MEI). * It doesn't appear to affect igb, although the only test hardware I have has igb as an "extra" port, so this may be inconclusive. * A workaround is given in the README. Changes imported from stable-1.5 branch: * Most new changes were imported as new patches as-is. * Changeset a73e8a537 "Fixed working counter calculation when process data of the same slave are split into separate datagrams." was not applied; the default branch already contains a completely different implementation of the affected functions by Dave Page (for overlapping PDO support). I'm not familiar enough with the code to tell whether it requires a similar change, but it looks like it was already resolved. * There are now 45 patches in here, which is getting a little silly. I hope they get merged upstream soon. * CAUTION: these patches include ones which change the installation directory and library filename. Changes may be required to applications or installation procedures to accommodate this. * This is evidently some strange usage of the word "stable" that I wasn't previously aware of. Changes to existing patches: * Some of the patches have been simply renumbered without other changes, due to changes to other patches. These won't be explicitly called out. * linux/0001-debugif-3.17.patch (was base/0031-debugif-3.17.patch) * Moved earlier in the patch series so that compilation of only the "stable" and "linux" groups (and possibly some of the "devices") works, if that's all you want. * linux/0002-kern_cont.patch (was base/0029-kern-cont.patch) * Moved similarly. * linux/0003-vm_fault-4.10.patch (was base/0005-support-vm_fault-kernel-v4.10.patch) * Moved similarly. * linux/0004-signal-4.11.patch (was base/0032-signal-4.11.patch) * Moved similarly. * devices/0002-update.patch * Simplified a bit since the stable patches now include an update script for the IGB driver. * devices/0006-linux-4.4.patch * While this patch has largely been dropped because its contents are now in stable patches, I did notice some bugs in the stable version of the e1000e driver, which this corrects. * devices/0007-linux-4.9.patch * Patch refreshed from the latest version of Linux 4.9. * devices/0008-linux-4.14.patch * Patch refreshed from the latest version of Linux 4.14. * features/master-redundancy/0001-e1000e-fix-watchdog-redundancy.patch (was devices/0002-RX-does-not-reset-watchdog-breaks-redundancy.patch) * Renamed and updated description to provide more explanation of intent. * The patch proposed by Wilfried Holzke in http://lists.etherlab.org/pipermail/etherlab-users/2018/003435.html is a direct revert of this patch, and suggests that it may cause problems for users of RTAI. I'm not sure why; this does kick some work off to a background thread, but that's necessary to reduce latency and should only be beneficial. (Unless perhaps RTAI is unable to tell Linux to schedule_work? That seems like a bug in RTAI if so.) * Consequently, I've demoted this patch to a feature patch to make it clearer what it's for and when it's needed. * There are two key changes in this patch: * The watchdog task is executed on a Linux background thread (via schedule_work) rather than in the RT thread. * This is what the driver does when not running in EtherCAT mode anyway. * This is necessary to reduce RT latency, since the watchdog task can be a bit slow. * The watchdog task is executed every 2 seconds regardless of whether packets are being received or not. * This is necessary when using master-level redundancy (--with-devices=2), because in that case typically one port is sending packets without ever receiving any, and the other port is receiving packets without ever sending any, and link detection does not work correctly in this scenario unless the watchdog is executed. * FYI it was c350fc89afd7 which first moved the work from a background thread onto the RT thread, although oddly only for Linux 2.6.37 and above. * Possibly some further changes are needed to resolve these issues. I'm open to ideas. * features/eoe-rtdm/* * Updates to EoE from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000689.html. * Note that this also proposes a new patch, which has instead been added as base/0020-eoe-ip.patch, as it's an important bugfix. * I've made a few additional modifications to these patches in order to compile clean without warnings. New patches: * linux/0005-tty-4.15.patch * Timer API changes and other fixes to TTY module for kernel 4.15 and later, sent privately from Michael Graichen. * I've modified his original patch a little, to fix some related compiler warnings and to remove the "old API emulation" that he put in, as the code is cleaner without it. * devices/0001-update.patch * Fixes some inconsistencies in the upstream device update scripts (after stable patches). * devices/0009-linux-4.19.patch * EtherCAT device drivers for Linux 4.19. As usual, these are mechanically patched and do compile, but I have not actually tested that they work. * The r8169 driver is not included, as it has been significantly rewritten in Linux 4.19 and I'm not sure how to safely patch it. * devices/0013-r8152-4.9.patch, devices/0014-r8152-3.18.patch, devices/0015-r8152-4.4.patch * Support for Realtek RTL8152/RTL8153, from http://lists.etherlab.org/pipermail/etherlab-users/2018/003495.html * base/0004-fix-eoe-clear.patch * Fixes typo in EoE request cancellation on slave disposal, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000705.html * base/0005-disable-eoe.patch * Fixes compilation with --disable-eoe, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000692.html * Some changes in the original patch have been folded into patches that appear later in the patchset instead. * base/0020-eoe-ip.patch * Fixes EoE mailbox conflict between IP state machine and packet state machine, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000689.html. * In an ideal world, rather than splitting separate message caches for each state machine, we'd have some way for a state machine to register a "reply filter/callback" for responses it cares about. But we're not in that world yet, and this patch is consistent with Knud Baastrup's previous changes. * Also in an ideal world this patch would be subdivided a bit further into separate patches which fix the IP command packet layout and split the mailbox processing etc. * base/0028-ec_master_exec_slave_fsms-external-datagram-fix.patch * Don't consume a slave ring datagram when not actually using it, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000693.html * features/xenomai3/0001-Support-Xenomai-version-3.patch * Support for Alchemy RTDM in Xenomai v3, from http://lists.etherlab.org/pipermail/etherlab-users/2018/003494.html * features/sii-wait-load/0001-slave-scan-retry.patch * Retry reading SII if an error occurs, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000691.html * features/sii-wait-load/0002-fsm_sii-loading-check.patch * Retry reading SII if the "loaded" bit is not set, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000691.html * features/pcap/0001-pcap-logging.patch * "ethercat pcap" command, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000698.html * I had to add a missing include in order to get this to compile. * Note that the current implementation is not suitable for continuous logging, but just for snapshot logging; it will record the first block of packets sent and received during startup, and then stop once the buffer is full. The "ethercat pcap" command can be used both to fetch the current buffer and also to clear the buffer, but some packets may be cleared without being reported. * There is also most likely a race condition between the record and clear operations; clearing may be ignored if the buffer is not full and a packet is sent/received concurrently. * Standard (non-RTDM) userspace applications should be immune from this race, due to locks being held. Kernel and RTDM apps have fewer locks. * Clearing should be respected for all application types once the buffer is full, but then of course some packets will not be recorded. * features/pcap/0002-runtime-size.patch * Modifies the above to make the logging size 0 by default but configurable at module load time (via the ethercat config file). This means that you can enable logging without recompiling the master; just restarting it. * features/pcap/0003-report-size.patch * Modifies some internals of the kernel/tool interface to fix a race condition that could cause "ethercat pcap" to report an error if the log is not yet full. * Note that the race on the clear operation is still present. * features/pcap/0004-high-precision.patch * Uses microsecond-precision timestamps in the pcap files instead of jiffie-precision (typically 1-10ms). * This is disabled (and jiffie precision is still used) when compiling for RTDM, due to Graeme Foot's note that do_gettimeofday is troublesome under RTAI. * features/mbg/0001-mailbox-gateway.patch * EtherCAT Mailbox Gateway server, from http://lists.etherlab.org/pipermail/etherlab-dev/2019/000706.html * I had to add some missing includes and fix a typo to get this to compile. I have not verified its behaviour myself. Dropped patches: * devices/0008-linux-4.13.patch * Patch dropped because 4.13 didn't end up being an LTS release. Use 4.14 instead. * base/0004-dc_user-tabs.patch * Patch dropped because stable patches fix the original problem. Patches not taken: * TTY support for newer kernels -- http://lists.etherlab.org/pipermail/etherlab-users/2018/003516.html * This appears to be incomplete. And the proposed changes seemed unnecessary when compiling for 4.19. Another related patch was accepted, though. * Typo in igb_main for 3.18 -- http://lists.etherlab.org/pipermail/etherlab-dev/2019/000690.html * This appears to be a bug in the upstream kernel, which is still not fixed today in 3.18 - it was not fixed until 4.1, by https://github.com/torvalds/linux/commit/2439fc4d71f71b47c. As such, since there might be other non-EtherCAT-related bugs, it seems best to recommend using a newer kernel if you want to use IGB, rather than trying to patch just this one thing. I think this addresses all patches sent to myself or to the mailing lists since the last patchset release. There was a period where I wasn't receiving messages from the list, however, so if I've missed one then I apologise. Please let me know if there are any other changes that ought to be included. 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.
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
