Hi,

I ran the test against latest netnext without my changes and they still fail. I
tried to reduce the bursts for multicast but it did not help.

On the instance below, it failed on subtest-1 of multicast (test-12). The test
just sends 1 packet of 100bytes. I just managed to recreate this and wanted to
inform you.

On the server:

Server says test # 12
detecting synchronization signal 100
acknowledging synchronization signal 100
detecting end of synchronization signal 100
end of synchronization signal 100
TIPC Server Multicast (RDM) test...STARTED!
AF_TIPC:NAMESEQ=(72,0,99)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,0,99)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,100,199)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,200,299)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,200,299)Socket bind for multicast successful
AF_TIPC:NAMESEQ=(72,300,399)Socket bind for multicast successful
sending synchronization signal 1
sent synchronization signal 1
got ack for synchronization signal 1
detecting synchronization signal 3
acknowledging synchronization signal 3
detecting end of synchronization signal 3
end of synchronization signal 3
===>Starting SubTest 1
Received on 0 sockets in subtest 0, expected 3
===>Finished SubTest 1: received 0 msgs of sz -1 at 3 sockets (1 per socket)
TEST FAILED Received wrong number of multicast messages
 errno = 110: Connection timed out

On the client:

Test # 12
detecting synchronization signal 99
acknowledging synchronization signal 99
detecting end of synchronization signal 99
end of synchronization signal 99
sending synchronization signal 100
sent synchronization signal 100
got ack for synchronization signal 100
TIPC Multicast (RDM) test...STARTED!
client_test_multicast:
detecting synchronization signal 1
acknowledging synchronization signal 1
detecting end of synchronization signal 1
end of synchronization signal 1
sending synchronization signal 3
sent synchronization signal 3
got ack for synchronization signal 3
===> Starting multicast subtest #1
detecting synchronization signal 4
!! ========= HANGS here =========== !!


On 08/30/2016 01:34 PM, Jon Maloy wrote:
> The multicast failure is known. It happens because I lowered the socket
> receive buffer size in commit 10724cc7bb783 ("tipc: redesign connection-level
> flow control") so that the send stream now occasionally get too big, and a
> message is rejected. I don't consider this an error, as a multicast sender
> always has to expect and prepare his code for such events.  I have not seen
> the problem in test #6, but it is easily imaginable that this is the same 
> issue.
>
> ///jon
>
>
>
> On 08/30/2016 06:02 AM, Xue, Ying wrote:
>>
>> Just a reminder: this issues might not be caused by your patches. So firstly
>> we need to identify if your patch set leads to the side effects. If not, they
>> are introduced by previous commits merged into mainline.
>>
>> Regards,
>>
>> Ying
>>
>> *From:*Parthasarathy Bhuvaragan 
>> [mailto:parthasarathy.bhuvara...@ericsson.com]
>> *Sent:* Tuesday, August 30, 2016 4:30 PM
>> *To:* Xue, Ying; tipc-discussion@lists.sourceforge.net;
>> jon.ma...@ericsson.com; ma...@donjonn.com
>> *Subject:* Re: [PATCH net-next v2 00/12] tipc: create socket FSM using
>> sk_state only
>>
>> Hi Ying,
>>
>> I tried to trigger this fault. I get a different error on the multicast test,
>> after about 2 hours.
>>  node1 ~ # ./tipcTS
>>  Received on 1 sockets in subtest 6, expected 2
>>  TEST FAILED Received wrong number of multicast messages
>>   errno = 11: Resource temporarily unavailable
>>
>> My client and server run on 2 qemu-guest's with 4 cpus. I will continue to
>> investigate this. Sorry for the late reply, as I got stuck with other issues
>> recently and couldn't focus on this.
>>
>> regards partha
>>
>> On 08/17/2016 12:40 PM, Xue, Ying wrote:
>>
>>     I have found the following issue after the series is applied to the
>> latest kernel:
>>
>>     Test # 8
>>
>>     TIPC TIPC_IMPORTANCE test...STARTED!
>>
>>     TEST FAILED unexpected number of send() errors errno = 113: No route to 
>> host
>>
>>     Test # 1
>>
>>     Below is the procedure of how to reproduce above error:
>>
>>     Prepare for two nodes. One is to run "tipcTS"; and on another node, we
>> use the below commands to repeatedly run tipcTC test case:
>>
>>     while [ true ]; do tipcTC 0; done
>>
>>     About after 2 or 3 hours, the error above will appear.
>>
>>     Regards,
>>
>>     Ying
>>
>>     -----Original Message-----
>>
>>     From: Parthasarathy Bhuvaragan
>> [mailto:parthasarathy.bhuvara...@ericsson.com]
>>
>>     Sent: Monday, August 15, 2016 5:19 PM
>>
>>     To:tipc-discussion@lists.sourceforge.net
>>     <mailto:tipc-discussion@lists.sourceforge.net>;jon.ma...@ericsson.com
>> <mailto:jon.ma...@ericsson.com>;ma...@donjonn.com <mailto:ma...@donjonn.com>;
>> Xue, Ying
>>
>>     Subject: [PATCH net-next v2 00/12] tipc: create socket FSM using sk_state
>> only
>>
>>     The following issues with the current socket layer hinders socket
>> diagnostics implementation, which led to this patch series. The series does
>> not add any functional change.
>>
>>     1. tipc socket state is derived from multiple variables like
>>
>>         sock->state, tsk->probing_state and tsk->connected. This style forces
>>
>>         us to export multiple attributes to the user space, which has to be
>>
>>         backward compatible.
>>
>>     2. Abuse of sock->state cannot be exported to user-space without
>>
>>         requiring tipc specific hacks in the user-space.
>>
>>         - For connection less (CL) sockets sock->state is overloaded to
>>
>>           tipc state SS_READY.
>>
>>         - For connection oriented (CO) listening socket sock->state is
>>
>>           overloaded to tipc state SS_LISTEN.
>>
>>     This series is split into three:
>>
>>     1. A bug fix in patch-1
>>
>>     2. Express all tipc states using a single variable. This is done in
>> patch#2-5.
>>
>>     3. Migrate the new tipc states to sk->sk_state. This is done in 
>> patch#6-12.
>>
>>     The figures below represents the FSM after this series:
>>
>>     Unconnected Sockets:
>>
>>     +------------------+        +--------------------+
>>
>>     | TIPC_UNCONNECTED |------->| TIPC_DISCONNECTING |
>>
>>     +------------------+        +--------------------+
>>
>>     Stream Server Listening Socket:
>>
>>     +------------------+        +-------------+
>>
>>     | TIPC_UNCONNECTED |------->| TIPC_LISTEN |
>>
>>     +------------------+        +-------------+
>>
>>                                        |
>>
>>     +--------------------+            |
>>
>>     | TIPC_DISCONNECTING |<-----------+
>>
>>     +--------------------+
>>
>>     Stream Server Data Socket:
>>
>>     +-----------------+        +------------------+
>>
>>     |TIPC_UNCONNECTED |------> | TIPC_ESTABLISHED |<---+
>>
>>     +-----------------+        +------------------+    |
>>
>>                                     ^   |    |          |
>>
>>                                     |   |    +----------+
>>
>>                                     |   v
>>
>>     +------------------+      +-------------+
>>
>>     |TIPC_DISCONNECTING|<-----|TIPC_PROBING |
>>
>>     +------------------+      +-------------+
>>
>>     Stream Socket Client:
>>
>>     +-----------------+       +-----------------+
>>
>>     |TIPC_UNCONNECTED |------>| TIPC_CONNECTING |
>>
>>     +-----------------+       +-----------------+
>>
>>                                        |
>>
>>                                        |
>>
>>                                        v
>>
>>                                +------------------+
>>
>>                                | TIPC_ESTABLISHED |<---+
>>
>>                                +------------------+    |
>>
>>                                     ^   |    |         |
>>
>>                                     |   |    +---------+
>>
>>                                     |   v
>>
>>     +------------------+      +-------------+
>>
>>     |TIPC_DISCONNECTING|<-----|TIPC_PROBING |
>>
>>     +------------------+      +-------------+
>>
>>     NOTE:
>>
>>     This is just a base refractoring required for socket diagnostics.
>>
>>     Implementation of TIPC socket diagnostics will be sent as a separate 
>> series.
>>
>>     v2: - Address comments from Ying Xue<ying....@windriver.com>
>> <mailto:ying....@windriver.com>  in
>>
>>            patch #4, #5, #12.
>>
>>          - Added a note that the socket diagnostics will be sent as
>>
>>            another series.
>>
>>     v1: - I base the following patch series as the first version:
>>
>>            [RFC PATCH v1 00/12] tipc: create socket FSM using sk_state only
>>
>>     Parthasarathy Bhuvaragan (12):
>>
>>        tipc: set kern=0 in sk_alloc() during tipc_accept()
>>
>>        tipc: rename tsk->remote to tsk->peer for consistent naming
>>
>>        tipc: remove tsk->connected for connection less sockets
>>
>>        tipc: remove tsk->connected from tipc_sock
>>
>>        tipc: remove probing_intv from tipc_sock
>>
>>        tipc: remove socket state SS_READY
>>
>>        tipc: create TIPC_LISTEN as a new sk_state
>>
>>        tipc: create TIPC_PROBING/TIPC_ESTABLISHED as new sk_states
>>
>>        tipc: create TIPC_UNCONNECTED as a new sk_state
>>
>>        tipc: create TIPC_DISCONNECTING as a new sk_state
>>
>>        tipc: create TIPC_CONNECTING as a new sk_state
>>
>>        tipc: remove SS_CONNECTED sock state
>>
>>       include/uapi/linux/tipc.h |  12 ++
>>
>>       net/tipc/socket.c         | 340
>> ++++++++++++++++++++++++++--------------------
>>
>>       2 files changed, 205 insertions(+), 147 deletions(-)
>>
>>     --
>>
>>     2.1.4
>>
>
>

------------------------------------------------------------------------------
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to