On 04/07/2016 11:46 AM, GUNA wrote:
> Thanks Jon & Richard.
>
> I am using 4.4.0 kernel and was told tipc-config should be good now,
> so I will keep it for a while.
>
> Regarding "ERROR DETECTED...", this seems our audit script displays
> the error for "STANDBY" nodes while expects "ACTIVE". Sin
Until now, the requests sent to topology server are queued
to a workqueue by the generic server framework.
These messages are processed by worker threads and trigger the
registered callbacks.
To reduce latency on uniprocessor systems, explicit rescheduling
is performed using cond_resched() after MA
From: Jon Maloy
Date: Thu, 7 Apr 2016 10:09:12 -0400
> When fix a minor buffer leak, and ensure that bearers filter packets
> correctly while they are being shut down.
>
> v2: Corrected typos in commit #3, as per feedback from S. Shtylyov
> v3: Removed commit #3 from the series. Improved versio
This series addresses some smaller issues regarding the link setup
algorithm. The first commit fixes a rare bug we have discovered during
testing; the second one may have some future impact on cluster
scalabilty, while two remaining ones can be regarded as cosmetic.
Jon Maloy (4):
tipc: guara
In some link establishment scenarios we see that packet #2 may be sent
out before packet #1, forcing the receiver to demand retransmission of
the missing packet. This is harmless, but may cause confusion among
people tracing the packet flow.
Since this is extremely easy to fix, we do so by adding
When a link endpoint is going down locally, e.g., because its interface
is being stopped, it will spontaneously send out a RESET message to
its peer, informing it about this fact. This saves the peer from
detecting the failure via probing, and hence gives both speedier and
less resource consuming f
The function tipc_link_timeout() is unnecessary complex, and can
easily be made more readable.
We do that with this commit. The only functional change is that we
remove a redundant test for whether the broadcast link is up or not.
Signed-off-by: Jon Maloy
---
net/tipc/link.c | 36 ++
When a link is down, it will continuously try to re-establish contact
with the peer by sending out a RESET or an ACTIVATE message at each
timeout interval. The default value for this interval is currently
375 ms. This is wasteful, and may become a problem in very large
clusters with dozens or hundr
Thanks Jon & Richard.
I am using 4.4.0 kernel and was told tipc-config should be good now,
so I will keep it for a while.
Regarding "ERROR DETECTED...", this seems our audit script displays
the error for "STANDBY" nodes while expects "ACTIVE". Since our system
supports redundancy, this is not an
Commit #1 fixes a potential issue with deferred binding table
updates being pushed to the wrong namespace.
Commit #2 solves a problem with deferred binding table updates
remaining in the the defer queue after the issuing node has gone
down.
Erik Hugne (2):
tipc: make dist queue pernet
tipc:
When fix a minor buffer leak, and ensure that bearers filter packets
correctly while they are being shut down.
v2: Corrected typos in commit #3, as per feedback from S. Shtylyov
v3: Removed commit #3 from the series. Improved version will be
re-submitted later.
Jon Maloy (2):
tipc: elimina
When enabling a bearer we create a 'neigbor discoverer' instance by
calling the function tipc_disc_create() before the bearer is actually
registered in the list of enabled bearers. Because of this, the very
first discovery broadcast message, created by the mentioned function,
is lost, since it cann
Resetting a bearer/interface, with the consequence of resetting all its
pertaining links, is not an atomic action. This becomes particularly
evident in very large clusters, where a lot of traffic may happen on the
remaining links while we are busy shutting them down. In extreme cases,
we may even s
Hi Partha,
Thanks for your explanation.
But in my opinion it's a bit overdesigned to fix the issue by introducing a
new lock.
So, I don't like the solution in V3. Tomorrow I will spend some time figuring
out whether there is a simpler solution.
Regards,
Ying
-Original Message-
From:
Hi,
On 2016-04-06 17:36, GUNA wrote:
> I upgraded kernel from 3.4.2 to 4.4.0 and noticed links were bouncing
> and not stable.
>
> There are a multitude of “Link not active” messages from audit_tipc.sh
> script, as you could see below, however the links are up from
> "tipc-config -l".
As a side n
15 matches
Mail list logo
