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.
sc-state-lock.patch
Description: Binary data
_______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
