Re: [tipc-discussion] Tipc: name table mismatch between different cards in a system

2016-05-04 Thread GUNA
I have seen the patch: tipc: move netlink policies to netlink.c
Does this patch has a tipc-config compatibility fix that Jon found earlier ?
However I don't see any change in netlink_compat.c.

From Jon:
"
When I run the "tipc" tool  I see the correct value, i.e., key == (portid + 1).
When I run tipc-config (which is deprecated in the new version), I see
the wrong value key == portid for the same publications!
"

// Guna

On Mon, May 2, 2016 at 1:22 PM, GUNA <gbala...@gmail.com> wrote:
> Is there any possibility getting the fix soon? Our audit scripts cause
> alarm due to incorrect table mismatch. If you point me the code to be
> fixed then I will fix it in my kernel. I am using kernel 4.4.0 on
> Fedora dist.
> Thanks in advance.
> Guna
>
> On Fri, Apr 29, 2016 at 11:55 AM, Jon Maloy <jon.ma...@ericsson.com> wrote:
>>
>>
>>> -Original Message-
>>> From: GUNA [mailto:gbala...@gmail.com]
>>> Sent: Friday, 29 April, 2016 10:48
>>> To: Jon Maloy
>>> Cc: tipc-discussion@lists.sourceforge.net
>>> Subject: Re: Tipc: name table mismatch between different cards in a system
>>>
>>> The two skb_linearize() calls and the update of ‘hdr' fixes are
>>> already in my load did not solve this issue. The issue remains same
>>> even after today's ACTIVE state fix (before one of link is STANDBY
>>> even same priority)
>>>
>>> // IO card, note this does not run latest kernel or tipc
>>> [root@10 ~]# tipc-config -nt |grep 2334480598
>>>20012  20012  <1.1.12:2334480598>2334480599  
>>> cluster
>>>
>>> // runs latest kernel on all CPU cards.
>>> [root@2 ~]# tipc-config -nt |grep 2334480598
>>> 50009  20012  20012  <1.1.12:2334480598>2334480598  
>>> cluster
>>
>> This was easy to reproduce, and actually looks like another presentation 
>> problem.
>>
>> When I run the "tipc" tool  I see the correct value, i.e., key == (portid + 
>> 1).
>> When I run tipc-config (which is deprecated in the new version), I see the 
>> wrong value key == portid for the same publications!
>>
>> So, your code will probably work correct, but the values presented will be 
>> wrong on the new version and correct on the old one.
>> I think this is something for Richard Alpe, who wrote the new netlink 
>> compatibility code, to take a look at.
>>
>> ///jon
>>
>>>
>>>
>>> On Thu, Apr 28, 2016 at 8:19 PM, GUNA <gbala...@gmail.com> wrote:
>>> > Thanks Jon. I already applied this patch on currently running module.
>>> >
>>> > On Thursday, April 28, 2016, Jon Maloy <jon.ma...@ericsson.com> wrote:
>>> >>
>>> >> Here it is. (This is just pasted into Outlook, so don’t try to apply it)
>>> >>
>>> >> If you manually add the two skb_linearize() calls and the update of ‘hdr’
>>> >> you should be safe.
>>> >>
>>> >>
>>> >>
>>> >> Good luck!
>>> >>
>>> >> ///jon
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> commit c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5
>>> >>
>>> >> Author: Jon Paul Maloy <jon.ma...@ericsson.com>
>>> >>
>>> >> Date:   Thu Nov 19 14:30:40 2015 -0500
>>> >>
>>> >>
>>> >>
>>> >> tipc: move linearization of buffers to generic code
>>> >>
>>> >>
>>> >>
>>> >> In commit 5cbb28a4bf65c7e4 ("tipc: linearize arriving NAME_DISTR
>>> >>
>>> >> and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR,
>>> >>
>>> >> LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function
>>> >>
>>> >> tipc_udp_recv(). The location of the change was selected in order
>>> >>
>>> >> to make the commit easily appliable to 'net' and 'stable'.
>>> >>
>>> >>
>>> >>
>>> >> We now move this linearization to where it should be done, in the
>>> >>
>>> >> functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.
>>> >>
>>> >>
>>> >>
>>> >> Reviewed-by: Ying Xue <ying@windriver.com>
>>> >>
>>&g

Re: [tipc-discussion] Tipc: name table mismatch between different cards in a system

2016-04-29 Thread GUNA
Thank you Jon.

Richard, could you let me know the fix for this please.

thanks,
Guna

On Fri, Apr 29, 2016 at 11:55 AM, Jon Maloy <jon.ma...@ericsson.com> wrote:
>
>
>> -Original Message-
>> From: GUNA [mailto:gbala...@gmail.com]
>> Sent: Friday, 29 April, 2016 10:48
>> To: Jon Maloy
>> Cc: tipc-discussion@lists.sourceforge.net
>> Subject: Re: Tipc: name table mismatch between different cards in a system
>>
>> The two skb_linearize() calls and the update of ‘hdr' fixes are
>> already in my load did not solve this issue. The issue remains same
>> even after today's ACTIVE state fix (before one of link is STANDBY
>> even same priority)
>>
>> // IO card, note this does not run latest kernel or tipc
>> [root@10 ~]# tipc-config -nt |grep 2334480598
>>20012  20012  <1.1.12:2334480598>2334480599  
>> cluster
>>
>> // runs latest kernel on all CPU cards.
>> [root@2 ~]# tipc-config -nt |grep 2334480598
>> 50009  20012  20012  <1.1.12:2334480598>2334480598  
>> cluster
>
> This was easy to reproduce, and actually looks like another presentation 
> problem.
>
> When I run the "tipc" tool  I see the correct value, i.e., key == (portid + 
> 1).
> When I run tipc-config (which is deprecated in the new version), I see the 
> wrong value key == portid for the same publications!
>
> So, your code will probably work correct, but the values presented will be 
> wrong on the new version and correct on the old one.
> I think this is something for Richard Alpe, who wrote the new netlink 
> compatibility code, to take a look at.
>
> ///jon
>
>>
>>
>> On Thu, Apr 28, 2016 at 8:19 PM, GUNA <gbala...@gmail.com> wrote:
>> > Thanks Jon. I already applied this patch on currently running module.
>> >
>> > On Thursday, April 28, 2016, Jon Maloy <jon.ma...@ericsson.com> wrote:
>> >>
>> >> Here it is. (This is just pasted into Outlook, so don’t try to apply it)
>> >>
>> >> If you manually add the two skb_linearize() calls and the update of ‘hdr’
>> >> you should be safe.
>> >>
>> >>
>> >>
>> >> Good luck!
>> >>
>> >> ///jon
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> commit c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5
>> >>
>> >> Author: Jon Paul Maloy <jon.ma...@ericsson.com>
>> >>
>> >> Date:   Thu Nov 19 14:30:40 2015 -0500
>> >>
>> >>
>> >>
>> >> tipc: move linearization of buffers to generic code
>> >>
>> >>
>> >>
>> >> In commit 5cbb28a4bf65c7e4 ("tipc: linearize arriving NAME_DISTR
>> >>
>> >> and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR,
>> >>
>> >> LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function
>> >>
>> >> tipc_udp_recv(). The location of the change was selected in order
>> >>
>> >> to make the commit easily appliable to 'net' and 'stable'.
>> >>
>> >>
>> >>
>> >> We now move this linearization to where it should be done, in the
>> >>
>> >> functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.
>> >>
>> >>
>> >>
>> >> Reviewed-by: Ying Xue <ying@windriver.com>
>> >>
>> >> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
>> >>
>> >> Signed-off-by: David S. Miller <da...@davemloft.net>
>> >>
>> >>
>> >>
>> >> diff --git a/net/tipc/link.c b/net/tipc/link.c
>> >>
>> >> index 9efbdbd..fa452fb 100644
>> >>
>> >> --- a/net/tipc/link.c
>> >>
>> >> +++ b/net/tipc/link.c
>> >>
>> >> @@ -1260,6 +1260,8 @@ static int tipc_link_proto_rcv(struct tipc_link *l,
>> >> struct sk_buff *skb,
>> >>
>> >> /* fall thru' */
>> >>
>> >> case ACTIVATE_MSG:
>> >>
>> >> +   skb_linearize(skb);
>> >>
>> >> +   hdr = buf_msg(skb);
>> >>
>> >> /* Complete own link name with peer's interface name */
>> >>
>> >> 

Re: [tipc-discussion] Tipc: name table mismatch between different cards in a system

2016-04-29 Thread Jon Maloy


> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Friday, 29 April, 2016 10:48
> To: Jon Maloy
> Cc: tipc-discussion@lists.sourceforge.net
> Subject: Re: Tipc: name table mismatch between different cards in a system
> 
> The two skb_linearize() calls and the update of ‘hdr' fixes are
> already in my load did not solve this issue. The issue remains same
> even after today's ACTIVE state fix (before one of link is STANDBY
> even same priority)
> 
> // IO card, note this does not run latest kernel or tipc
> [root@10 ~]# tipc-config -nt |grep 2334480598
>20012  20012  <1.1.12:2334480598>2334480599  
> cluster
> 
> // runs latest kernel on all CPU cards.
> [root@2 ~]# tipc-config -nt |grep 2334480598
> 50009  20012  20012  <1.1.12:2334480598>2334480598  
> cluster

This was easy to reproduce, and actually looks like another presentation 
problem.

When I run the "tipc" tool  I see the correct value, i.e., key == (portid + 1).
When I run tipc-config (which is deprecated in the new version), I see the 
wrong value key == portid for the same publications!

So, your code will probably work correct, but the values presented will be 
wrong on the new version and correct on the old one.
I think this is something for Richard Alpe, who wrote the new netlink 
compatibility code, to take a look at.

///jon

> 
> 
> On Thu, Apr 28, 2016 at 8:19 PM, GUNA <gbala...@gmail.com> wrote:
> > Thanks Jon. I already applied this patch on currently running module.
> >
> > On Thursday, April 28, 2016, Jon Maloy <jon.ma...@ericsson.com> wrote:
> >>
> >> Here it is. (This is just pasted into Outlook, so don’t try to apply it)
> >>
> >> If you manually add the two skb_linearize() calls and the update of ‘hdr’
> >> you should be safe.
> >>
> >>
> >>
> >> Good luck!
> >>
> >> ///jon
> >>
> >>
> >>
> >>
> >>
> >> commit c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5
> >>
> >> Author: Jon Paul Maloy <jon.ma...@ericsson.com>
> >>
> >> Date:   Thu Nov 19 14:30:40 2015 -0500
> >>
> >>
> >>
> >> tipc: move linearization of buffers to generic code
> >>
> >>
> >>
> >> In commit 5cbb28a4bf65c7e4 ("tipc: linearize arriving NAME_DISTR
> >>
> >> and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR,
> >>
> >> LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function
> >>
> >> tipc_udp_recv(). The location of the change was selected in order
> >>
> >> to make the commit easily appliable to 'net' and 'stable'.
> >>
> >>
> >>
> >> We now move this linearization to where it should be done, in the
> >>
> >> functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.
> >>
> >>
> >>
> >> Reviewed-by: Ying Xue <ying@windriver.com>
> >>
> >> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
> >>
> >> Signed-off-by: David S. Miller <da...@davemloft.net>
> >>
> >>
> >>
> >> diff --git a/net/tipc/link.c b/net/tipc/link.c
> >>
> >> index 9efbdbd..fa452fb 100644
> >>
> >> --- a/net/tipc/link.c
> >>
> >> +++ b/net/tipc/link.c
> >>
> >> @@ -1260,6 +1260,8 @@ static int tipc_link_proto_rcv(struct tipc_link *l,
> >> struct sk_buff *skb,
> >>
> >> /* fall thru' */
> >>
> >> case ACTIVATE_MSG:
> >>
> >> +   skb_linearize(skb);
> >>
> >> +   hdr = buf_msg(skb);
> >>
> >> /* Complete own link name with peer's interface name */
> >>
> >> if_name =  strrchr(l->name, ':') + 1;
> >>
> >> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
> >>
> >> index c07612b..f51c8bd 100644
> >>
> >> --- a/net/tipc/name_distr.c
> >>
> >> +++ b/net/tipc/name_distr.c
> >>
> >> @@ -397,6 +397,7 @@ void tipc_named_rcv(struct net *net, struct
> >> sk_buff_head *inputq)
> >>
> >> spin_lock_bh(>nametbl_lock);
> >>
> >> for (skb = skb_dequeue(inputq); skb; skb = skb_dequeue(inputq)) {
> >>
> >> +   skb_linearize(skb);
> >>
> >&

Re: [tipc-discussion] Tipc: name table mismatch between different cards in a system

2016-04-28 Thread GUNA
Thanks Jon. I already applied this patch on currently running module.

On Thursday, April 28, 2016, Jon Maloy <jon.ma...@ericsson.com> wrote:

> Here it is. (This is just pasted into Outlook, so don’t try to apply it)
>
> If you manually add the two skb_linearize() calls and the update of ‘hdr’
> you should be safe.
>
>
>
> Good luck!
>
> ///jon
>
>
>
>
>
> commit c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5
>
> Author: Jon Paul Maloy <jon.ma...@ericsson.com
> <javascript:_e(%7B%7D,'cvml','jon.ma...@ericsson.com');>>
>
> Date:   Thu Nov 19 14:30:40 2015 -0500
>
>
>
> tipc: move linearization of buffers to generic code
>
>
>
> In commit 5cbb28a4bf65c7e4 ("tipc: linearize arriving NAME_DISTR
>
> and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR,
>
> LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function
>
> tipc_udp_recv(). The location of the change was selected in order
>
> to make the commit easily appliable to 'net' and 'stable'.
>
>
>
> We now move this linearization to where it should be done, in the
>
> functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.
>
>
>
> Reviewed-by: Ying Xue <ying@windriver.com
> <javascript:_e(%7B%7D,'cvml','ying@windriver.com');>>
>
> Signed-off-by: Jon Maloy <jon.ma...@ericsson.com
> <javascript:_e(%7B%7D,'cvml','jon.ma...@ericsson.com');>>
>
> Signed-off-by: David S. Miller <da...@davemloft.net
> <javascript:_e(%7B%7D,'cvml','da...@davemloft.net');>>
>
>
>
> diff --git a/net/tipc/link.c b/net/tipc/link.c
>
> index 9efbdbd..fa452fb 100644
>
> --- a/net/tipc/link.c
>
> +++ b/net/tipc/link.c
>
> @@ -1260,6 +1260,8 @@ static int tipc_link_proto_rcv(struct tipc_link *l,
> struct sk_buff *skb,
>
> /* fall thru' */
>
> case ACTIVATE_MSG:
>
> +   skb_linearize(skb);
>
> +   hdr = buf_msg(skb);
>
> /* Complete own link name with peer's interface name */
>
> if_name =  strrchr(l->name, ':') + 1;
>
> diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
>
> index c07612b..f51c8bd 100644
>
> --- a/net/tipc/name_distr.c
>
> +++ b/net/tipc/name_distr.c
>
> @@ -397,6 +397,7 @@ void tipc_named_rcv(struct net *net, struct
> sk_buff_head *inputq)
>
> spin_lock_bh(>nametbl_lock);
>
> for (skb = skb_dequeue(inputq); skb; skb = skb_dequeue(inputq)) {
>
> +   skb_linearize(skb);
>
> msg = buf_msg(skb);
>
> mtype = msg_type(msg);
>
> item = (struct distr_item *)msg_data(msg);
>
> diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
>
> index ad2719a..816914e 100644
>
> --- a/net/tipc/udp_media.c
>
> +++ b/net/tipc/udp_media.c
>
> @@ -48,7 +48,6 @@
>
> #include 
>
> #include "core.h"
>
> #include "bearer.h"
>
> -#include "msg.h"
>
>  /* IANA assigned UDP port */
>
> #define UDP_PORT_DEFAULT   6118
>
> @@ -221,10 +220,6 @@ static int tipc_udp_recv(struct sock *sk, struct
> sk_buff *skb)
>
> {
>
> struct udp_bearer *ub;
>
> struct tipc_bearer *b;
>
> -   int usr = msg_user(buf_msg(skb));
>
> -
>
> -   if ((usr == LINK_PROTOCOL) || (usr == NAME_DISTRIBUTOR))
>
> -   skb_linearize(skb);
>
> ub = rcu_dereference_sk_user_data(sk);
>
> if (!ub) {
>
>
>
> *From:* GUNA [mailto:gbala...@gmail.com
> <javascript:_e(%7B%7D,'cvml','gbala...@gmail.com');>]
> *Sent:* Thursday, 28 April, 2016 19:24
> *To:* Jon Maloy
> *Cc:* tipc-discussion@lists.sourceforge.net
> <javascript:_e(%7B%7D,'cvml','tipc-discussion@lists.sourceforge.net');>
> *Subject:* Re: Tipc: name table mismatch between different cards in a
> system
>
>
>
> See inline
>
> On Thursday, April 28, 2016, Jon Maloy <jon.ma...@ericsson.com
> <javascript:_e(%7B%7D,'cvml','jon.ma...@ericsson.com');>> wrote:
>
>
>
> > -Original Message-
> > From: GUNA [mailto:gbala...@gmail.com]
> > Sent: Thursday, 28 April, 2016 17:43
> > To: tipc-discussion@lists.sourceforge.net
> > Subject: [tipc-discussion] Tipc: name table mismatch between different
> cards in a
> > system
> >
> > After upgraded CPU cards to 4.4.0 Kernel, there is table mismatch between
> > CPU and IO cards. The IO Publication value = CPU Publication + 1 as you
> see
> > example below:
> >
> > In CPU (s

Re: [tipc-discussion] Tipc: name table mismatch between different cards in a system

2016-04-28 Thread Jon Maloy
Here it is. (This is just pasted into Outlook, so don’t try to apply it)
If you manually add the two skb_linearize() calls and the update of ‘hdr’ you 
should be safe.

Good luck!
///jon


commit c7cad0d6f70cd4ce8644ffe528a4df1cdc2e77f5
Author: Jon Paul Maloy <jon.ma...@ericsson.com>
Date:   Thu Nov 19 14:30:40 2015 -0500

tipc: move linearization of buffers to generic code

In commit 5cbb28a4bf65c7e4 ("tipc: linearize arriving NAME_DISTR
and LINK_PROTO buffers") we added linearization of NAME_DISTRIBUTOR,
LINK_PROTOCOL/RESET and LINK_PROTOCOL/ACTIVATE to the function
tipc_udp_recv(). The location of the change was selected in order
to make the commit easily appliable to 'net' and 'stable'.

We now move this linearization to where it should be done, in the
functions tipc_named_rcv() and tipc_link_proto_rcv() respectively.

Reviewed-by: Ying Xue <ying@windriver.com>
Signed-off-by: Jon Maloy <jon.ma...@ericsson.com>
Signed-off-by: David S. Miller <da...@davemloft.net>

diff --git a/net/tipc/link.c b/net/tipc/link.c
index 9efbdbd..fa452fb 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1260,6 +1260,8 @@ static int tipc_link_proto_rcv(struct tipc_link *l, 
struct sk_buff *skb,
/* fall thru' */
case ACTIVATE_MSG:
+   skb_linearize(skb);
+   hdr = buf_msg(skb);
/* Complete own link name with peer's interface name */
if_name =  strrchr(l->name, ':') + 1;
diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index c07612b..f51c8bd 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -397,6 +397,7 @@ void tipc_named_rcv(struct net *net, struct sk_buff_head 
*inputq)
spin_lock_bh(>nametbl_lock);
for (skb = skb_dequeue(inputq); skb; skb = skb_dequeue(inputq)) {
+   skb_linearize(skb);
msg = buf_msg(skb);
mtype = msg_type(msg);
item = (struct distr_item *)msg_data(msg);
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
index ad2719a..816914e 100644
--- a/net/tipc/udp_media.c
+++ b/net/tipc/udp_media.c
@@ -48,7 +48,6 @@
#include 
#include "core.h"
#include "bearer.h"
-#include "msg.h"
 /* IANA assigned UDP port */
#define UDP_PORT_DEFAULT   6118
@@ -221,10 +220,6 @@ static int tipc_udp_recv(struct sock *sk, struct sk_buff 
*skb)
{
struct udp_bearer *ub;
struct tipc_bearer *b;
-   int usr = msg_user(buf_msg(skb));
-
-   if ((usr == LINK_PROTOCOL) || (usr == NAME_DISTRIBUTOR))
-   skb_linearize(skb);
ub = rcu_dereference_sk_user_data(sk);
if (!ub) {

From: GUNA [mailto:gbala...@gmail.com]
Sent: Thursday, 28 April, 2016 19:24
To: Jon Maloy
Cc: tipc-discussion@lists.sourceforge.net
Subject: Re: Tipc: name table mismatch between different cards in a system

See inline

On Thursday, April 28, 2016, Jon Maloy 
<jon.ma...@ericsson.com<mailto:jon.ma...@ericsson.com>> wrote:


> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com<javascript:;>]
> Sent: Thursday, 28 April, 2016 17:43
> To: tipc-discussion@lists.sourceforge.net<javascript:;>
> Subject: [tipc-discussion] Tipc: name table mismatch between different cards 
> in a
> system
>
> After upgraded CPU cards to 4.4.0 Kernel, there is table mismatch between
> CPU and IO cards. The IO Publication value = CPU Publication + 1 as you see
> example below:
>
> In CPU (slot 2)
>
> Type   Lower  Upper  Port Identity   Publication
>
> 16789314 3201 3201 <1.1.6:1540208445>   1540208445
>
> 16789823 4 4 <1.1.6:3035967304>   3035967304
>
> 16832168 3201 3201 <1.1.6:723652841> 723652841
>
> …
>
>
>
> In IO (slot10)
>
> 16789314 3201 3201 <1.1.6:1540208445>  1540208446
>
> 16789823 4 4 <1.1.6:3035967304>  3035967305
>
> 16832168 3201 3201 <1.1.6:723652841>723652842
>
> …

This looks like another artefact of the problem we have in 4.4 with corrupted 
entries, where old entries are not withdrawn, so the new ones cannot replace 
them in "CPU", while it happens to work in "IO".   If  1.1.6 is "IO" or a third 
node this could make sense.

1.1.6 is node6 but I see similar for all other nodes as well. Ie: same for 
1.1.2,1.1.3,1.1.13.


This problem has been fixed in Ubuntu 16.04, but has not been released yet. I 
would suggest you try 4.5 or 4.6rc4 to see if it disappears. According to Rune 
Torgersen it is definitely working in 4.6.

///jon

I could not move to new kernel now, but I could rebuild the 4.4.0 if I get the 
fix.
If you are aware of the fix please let me know detail of the fix.

>
>
> All the entries are 

Re: [tipc-discussion] Tipc: name table mismatch between different cards in a system

2016-04-28 Thread GUNA
See inline

On Thursday, April 28, 2016, Jon Maloy  wrote:

>
>
> > -Original Message-
> > From: GUNA [mailto:gbala...@gmail.com ]
> > Sent: Thursday, 28 April, 2016 17:43
> > To: tipc-discussion@lists.sourceforge.net 
> > Subject: [tipc-discussion] Tipc: name table mismatch between different
> cards in a
> > system
> >
> > After upgraded CPU cards to 4.4.0 Kernel, there is table mismatch between
> > CPU and IO cards. The IO Publication value = CPU Publication + 1 as you
> see
> > example below:
> >
> > In CPU (slot 2)
> >
> > Type   Lower  Upper  Port Identity   Publication
> >
> > 16789314 3201 3201 <1.1.6:1540208445>   1540208445
> >
> > 16789823 4 4 <1.1.6:3035967304>   3035967304
> >
> > 16832168 3201 3201 <1.1.6:723652841> 723652841
> >
> > …
> >
> >
> >
> > In IO (slot10)
> >
> > 16789314 3201 3201 <1.1.6:1540208445>  1540208446
> >
> > 16789823 4 4 <1.1.6:3035967304>  3035967305
> >
> > 16832168 3201 3201 <1.1.6:723652841>723652842
> >
> > …
>
> This looks like another artefact of the problem we have in 4.4 with
> corrupted entries, where old entries are not withdrawn, so the new ones
> cannot replace them in "CPU", while it happens to work in "IO".   If  1.1.6
> is "IO" or a third node this could make sense.


1.1.6 is node6 but I see similar for all other nodes as well. Ie: same for
1.1.2,1.1.3,1.1.13.



> This problem has been fixed in Ubuntu 16.04, but has not been released
> yet. I would suggest you try 4.5 or 4.6rc4 to see if it disappears.
> According to Rune Torgersen it is definitely working in 4.6.
>
> ///jon
>
>
I could not move to new kernel now, but I could rebuild the 4.4.0 if I get
the fix.
If you are aware of the fix please let me know detail of the fix.


> >
> >
> > All the entries are similar pattern in both IO & CPU. The CPU match with
> > rest of the CPUs.
> >
> >
> > The system runs on previous kernel did not see this issue.
> >
> >
> > There are two links on IO and CPU cards.  Both links are ACTIVE in IO and
> > in CPU one ACTIVE and other STANDBY.
> >
> > Is that cause the issue?  If so, is it possible to make both links to be
> > ACTIVE ?
> >
> >
> > // IO
> >
> > Link <1.1.10:eth0-1.1.2:p19p1>
> >
> >   ACTIVE  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> >
> > Link <1.1.10:eth1-1.1.2:p19p2>
> >
> >   ACTIVE  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> >
> > // CPU
> > Link <1.1.2:p19p1-1.1.10:eth0>
> >   ACTIVE  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> >
> > Link <1.1.2:p19p2-1.1.10:eth1>
> >   STANDBY  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> >
> > thanks,
> >
> > Guna
> >
> --
> > 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!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___
> > tipc-discussion mailing list
> > tipc-discussion@lists.sourceforge.net 
> > 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!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion


Re: [tipc-discussion] Tipc: name table mismatch between different cards in a system

2016-04-28 Thread Jon Maloy


> -Original Message-
> From: GUNA [mailto:gbala...@gmail.com]
> Sent: Thursday, 28 April, 2016 17:43
> To: tipc-discussion@lists.sourceforge.net
> Subject: [tipc-discussion] Tipc: name table mismatch between different cards 
> in a
> system
> 
> After upgraded CPU cards to 4.4.0 Kernel, there is table mismatch between
> CPU and IO cards. The IO Publication value = CPU Publication + 1 as you see
> example below:
> 
> In CPU (slot 2)
> 
> Type   Lower  Upper  Port Identity   Publication
> 
> 16789314 3201 3201 <1.1.6:1540208445>   1540208445
> 
> 16789823 4 4 <1.1.6:3035967304>   3035967304
> 
> 16832168 3201 3201 <1.1.6:723652841> 723652841
> 
> …
> 
> 
> 
> In IO (slot10)
> 
> 16789314 3201 3201 <1.1.6:1540208445>  1540208446
> 
> 16789823 4 4 <1.1.6:3035967304>  3035967305
> 
> 16832168 3201 3201 <1.1.6:723652841>723652842
> 
> …

This looks like another artefact of the problem we have in 4.4 with corrupted 
entries, where old entries are not withdrawn, so the new ones cannot replace 
them in "CPU", while it happens to work in "IO".   If  1.1.6 is "IO" or a third 
node this could make sense.
This problem has been fixed in Ubuntu 16.04, but has not been released yet. I 
would suggest you try 4.5 or 4.6rc4 to see if it disappears. According to Rune 
Torgersen it is definitely working in 4.6.

///jon

> 
> 
> All the entries are similar pattern in both IO & CPU. The CPU match with
> rest of the CPUs.
> 
> 
> The system runs on previous kernel did not see this issue.
> 
> 
> There are two links on IO and CPU cards.  Both links are ACTIVE in IO and
> in CPU one ACTIVE and other STANDBY.
> 
> Is that cause the issue?  If so, is it possible to make both links to be
> ACTIVE ?
> 
> 
> // IO
> 
> Link <1.1.10:eth0-1.1.2:p19p1>
> 
>   ACTIVE  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> 
> Link <1.1.10:eth1-1.1.2:p19p2>
> 
>   ACTIVE  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> 
> // CPU
> Link <1.1.2:p19p1-1.1.10:eth0>
>   ACTIVE  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> 
> Link <1.1.2:p19p2-1.1.10:eth1>
>   STANDBY  MTU:1500  Priority:10  Tolerance:1200 ms  Window:50 packets
> 
> thanks,
> 
> Guna
> --
> 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!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> tipc-discussion mailing list
> tipc-discussion@lists.sourceforge.net
> 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!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion