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 <gav...@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@etherlab.org > http://lists.etherlab.org/mailman/listinfo/etherlab-dev > -- Ricardo Ribalda _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev