[etherlab-dev] Unofficial patchset update 20171102

[Ricardo Ribalda Delgado]

Hi Gavin, Hi All

I have took the liberty to merge the original repo, plus your patches,
plus the patches that I use into a github repository.

https://github.com/ribalda/ethercat

Anyone who wants to use it and report bugs is more than wellcome.

Regards!

On Fri, Nov 3, 2017 at 3:33 AM, Gavin Lambert <gavinl at compacsort.com> wrote:
> 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.
>
>
> _______________________________________________
> etherlab-dev mailing list
> etherlab-dev at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-dev
>



-- 
Ricardo Ribalda