[etherlab-dev] Unofficial patchset update 20171102

[Gavin Lambert]

Hi all,

I've just updated the unofficial patchset to version 20171102.  It is still
based on the same upstream default commit as before: 33b922.

https://sourceforge.net/u/uecasm/etherlab-patches/ci/default/tree/#readme

Notable changes since the last release:

* I've added a new "stable" directory of patches; these contain commits that
have been made upstream to the stable-1.5 branch but not yet to the default
branch.  I only looked at recent history for these so it's entirely possible
that I've missed a few.  But notable inclusions among these are an update to
the CCAT driver and the new IGB driver.

* I've dropped the old driver patches for Linux 4.9 and replaced them with
new patches for all drivers (including IGB) for Linux 3.18, 4.1, 4.4, and
4.9.  As usual since I don't have the hardware myself all I can guarantee is
that the orig code matches what was in the kernel sources (specifically the
vanilla+rt sources, in case it makes a difference) and that the EtherCAT
versions do compile.  I've made my best effort to forward-port the patches
but I can't make any promises that they'll work or have no bugs or memory
leaks.

* New patch base/0030-ext-timeout.patch: if you have a large domain, a fast
cycle, and many concurrent slave requests in progress, it can happen that
there is too much data to safely fit into the cycle, so the master wants to
defer some of the slave requests to the next cycle.  When it does this, it
tries to check when they were originally queued and timeout the requests
beyond a short interval to prevent them being stuck forever -- however the
time it checks against is not actually the time they were queued but rather
the time that the *previous* datagram using the same "slot" was actually
sent, which is obviously silly and tends to always time out the request
datagrams even when not necessary.  This patch fixes that.

Additionally, there's one further patch which I have *not* included in the
patchset, but merely attached to this message for review, because I can't
decide whether it's a good idea to include it or not.  The issue is that
when you call ecrt_slave_config_state it performs no locking and returns
some cached state inside both sc and sc->slave (and patch
features/status/0001 adds a few more things from inside sc->slave).  There's
even a comment indicating that no locks are required to protect sc, which is
true (at least as long as the application is not being dumb).  The trouble
is that if a rescan is in progress (or just about to start) then it is
possible for sc->slave to become NULL inside the method, which in turn
causes a kernel BUG report -- but after this everything continues running
correctly.  The patch adds a lock to resolve this race condition, but I'm a
little hesitant about including it as I don't like the idea of potentially
slowing down ecrt_slave_config_state (as it might be called a *lot* by the
application on large networks), and rescans should be quite rare during
normal operation.  (I noticed this when I had made an experimental change
which caused rescanning to occur nearly constantly.)  Feedback is welcomed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sc-state-lock.patch
Type: application/octet-stream
Size: 1084 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20171103/c8ba6baa/attachment.obj>