Hi Guna, See below.
On 04/08/2016 03:45 PM, GUNA wrote: > I have merged the fixes listed below into 4.4.0 kernel and rebuilt tipc > module. > Now, the links are look stable. Hm, I thought your "unstable" links were just due to your audit script. Nothing was changed in the patches you were applying that should change the link stability. > However, I do still see following alarms: > 1. "Name table mismatch ..." alarm > 2. "Dropping Name Table update" > > Questions: > 1. I thought the fix will resolve the above errors but they are still > exist. However links are better now. Why the fix did not work to > resolve above errors? Am I missing any other fixes? That was clearly the intention. This was an identified problem which I haven't seen since I created this commit. The logs from Rune Torgersen matched perfectly with this problem, so now I am slightly confused. From his logs I could defer that the header of the "bulk" message always was right (correct source node and data length), while the data area sometimes was corrupted when applied, but never on the wire. This indicates that the "item" pointer in tipc_named_rcv() is pointing into a non-linear buffer. Those corrupted "items" that happen to pass the correctness filter are added to the name table, while those which don't are added to the backlog and later purged. I could observe that the sum of those items matched with the number of publications passed in the bulk message, and that all other publications, passed in other messages, were applied correctly. I wonder if you, since you are now building your own kernel and are able to reproduce the problem, could help me a little: 1) Enable the printouts "Lost link..." and "Established link..." in node.c and observe in the kernel log if those links really are (or were, before your patches) instable. I have no indications of such a problem from anybody else, but the dual-link implementation is relatively recently rewritten, so things may happen despite all my testing. 2) Could you print out more info about the items added to the backlog, at the moment it happens. Are they corrupt? Is it publications or withdrawals? Why are they not accepted into the name table right away? Does it indeed happen when you receive a non-linear buffer, or even at other times? I am also aware that you are running a different system from Rune, so the problems you encounter may not even be the same. 3) Do you see name table inconsistencies when you run single links instead of dual links? (or even link flapping?) - Can you also confirm that you are running the dual links in active-standby mode (i.e., that you have set the priority of one bearer lower than the other?) Or is it active-active? - Do you see corrupt name table entries? (they typically contain lots of zeros and seemingly random numbers). - Do you use port name sequences (i.e., upper > lower), and if so, overlapping such from different nodes? (this was clearly not Rune's problem) Regards ///jon > > // from 4.5 > // tipc: move linearization of buffers to generic code > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5 > > // tipc: small cleanup of function tipc_node_check_state() > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5c10e9794013143eec80d494603d46dcb219970a > > // tipc: fix premature addition of node to lookup table > https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.4.y&id=692925fe2d42092a99d3532cb03932c8fda57786 > > // From 4.6 > // tipc: don't check link reset on non existing link > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5c10e9794013143eec80d494603d46dcb219970a > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ > gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 > _______________________________________________ > tipc-discussion mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
