tipc-discussion — User questions & problem reports, project news, developer discussion

[Tipc-discussion] sendbcast/recvbcast patch

[Mark H. <ma...@os...>]

I went through sendbcast and recvbcast and fixed the return codes. 
While I was in there I updated the comments headers to reflect what the
functions actually return and fixed some line length problems.

I had to change a couple returns of TIPC_ERR_NO_PORT and
TIPC_ERR_NO_NAME to be TIPC_FAILURE since the expected return value is a
message size.  TIPC_ERR_NO_NAME and TIPC_ERR_NO_PORT are positive
numbers and could be confused with messages sizes, where TIPC_FAILURE is
-22 and can not be confused with a size.

Mark.


cvs diff -u recvbcast.c sendbcast.c
Index: recvbcast.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/recvbcast.c,v
retrieving revision 1.20
diff -u -r1.20 recvbcast.c
--- recvbcast.c	26 May 2004 01:31:04 -0000	1.20
+++ recvbcast.c	26 May 2004 16:57:21 -0000
@@ -215,11 +215,14 @@
 }
 
 /**
-  *  Add the buf to the ownership node  deferred queue,update defer_inqueue size and gap
+  *  Add the buf to the ownership node  deferred queue,update defer_inqueue 
+  *  size and gap.
+  *
   *  Input:  this:  the link buf belonged
-  *		   buf: to be added to deffer queue
-  *  Return: 1: true
-  *		    0: false
+  *	      buf: to be added to deffer queue
+  *
+  *  Return: 	1: true
+  *	    	0: false
   */
 
 static int
@@ -241,9 +244,12 @@
 }
 
 /**
-  *  Recaulte the gap, accord to the defer queue packet's seqno, reorgnize them and send them
-  *  to port, update the gap, defer_queue_size, last_in_bcast.
+  *  Recaulte the gap, accord to the defer queue packet's seqno, reorgnize 
+  *  them and send them to port, update the gap, defer_queue_size, 
+  *  last_in_bcast.
+  *
   *  Input:  this:  link
+  *
   *  Return: void  
   */
 static void
@@ -276,7 +282,8 @@
 /**
   * process the bcast_nextsend in TIPC header. 
   * input: this: link
-  *		buf: recv buf
+  *	    buf: recv buf
+  *
   * return:void
   */
 void
@@ -307,10 +314,12 @@
 }
 
 /**
-  * recieve the bcast data,case seqno equal to expect number,recv them, if greater than
-  * expect seqno, add to defer queue.
+  * recieve the bcast data,case seqno equal to expect number,recv them, 
+  * if greater than expect seqno, add to defer queue.
+  *
   * input: this: link
-  *		buf: recv buf
+  *	    buf: recv buf
+  *
   * return:void 
   */
 void
@@ -374,9 +383,12 @@
 }
 
 /**
-  * recieved the retransmit packet, which has been wraped, extract the buf and send to upper layer
+  * recieved the retransmit packet, which has been wraped, extract the 
+  * buf and send to upper layer
+  *
   * input: this: link
-  *		buf: recv buf
+  *	    buf: recv buf
+  *
   * return:void 
   */
 
@@ -399,7 +411,8 @@
 /**
   * recieved the bcast state packet, handle retransmit.
   * input: this: link
-  *		buf: recv buf
+  * 	    buf: recv buf
+  *
   * return:void 
   */
 void
@@ -434,8 +447,10 @@
 /**
   * deliver the buf to multicast member
   * input: mc_head: mc_idenity list head
-  *		buf: recv buf
-  * return:void 
+  *	       buf: recv buf
+  *
+  * return:	message data size:	success
+  * 		            other:	failure
   */
 
 int
@@ -444,8 +459,8 @@
 
 	struct list_head *pos;
 	struct mc_identity *mid;
-	int res = TIPC_OK;
-	int sz = msg_data_sz(buf_msg(buf));
+	int res = msg_data_sz(buf_msg(buf));
+	int sz;
 
 	dbg("nameseq_deliver\n");
 	list_for_each(pos, mc_head) {
@@ -457,7 +472,7 @@
 			msg_set_user(buf_msg(copymsg), 0);
 			msg_set_destport(buf_msg(copymsg), mid->port);
 			if (port) {
-				res = port_recv_msg(copymsg);
+				sz = port_recv_msg(copymsg);
 				if (res != sz)
 					break;
 			}
@@ -469,8 +484,10 @@
 
 /**
   * request to retransmit the messages
-  * input: this:use the link to send back the retransmit requests
-  *		gap: the seqno gap
+  *
+  * input: this: use the link to send back the retransmit requests
+  *	    gap: the seqno gap
+  *
   * return:void 
   */
 
@@ -482,9 +499,11 @@
 }
 
 /**
-  * check bcast out queue, select the minmum ack seqno and deleted all the packets which
-  * seqno is less than the minmum seqno
+  * check bcast out queue, select the minmum ack seqno and deleted all 
+  * the packets which seqno is less than the minmum seqno
+  *
   * input: void
+  *
   * return:void 
   */
 
@@ -518,7 +537,8 @@
   * lower level recv bcast proto message handle, differentiate their types and 
   * call corresponding function
   * input: this:link
-  *		buf: the recieved buffer
+  *	    buf: the recieved buffer
+  *
   * return:void 
   */
 
@@ -550,16 +570,19 @@
 }
 
 /**
-  * port recieved function, get the mc idenity list and deliever the buf to the mc member  
+  * port recieved function, get the mc idenity list and deliever the buf 
+  * to the mc member.
+  *
   * input: buf: the recieved buffer
-  * return:void 
+  *
+  * return:	message data size:	success
+  * 			    other:	failure
   */
-
 int
 bcast_port_recv(struct sk_buff *buf)
 {
 	struct list_head mc_head;
-	int res = true;
+	int res;
 	struct tipc_msg *msg = buf_msg(buf);
 
 	INIT_LIST_HEAD(&mc_head);
@@ -569,7 +592,7 @@
 					    msg_nameupper(msg))) {
 		dbg("get TIPC_ERR_NO_PORT\n");
 		buf_safe_discard(buf);
-		return TIPC_ERR_NO_PORT;
+		return TIPC_FAILURE;
 	}
 	res = nameseq_deliver(buf, &mc_head);
 	free_mclist(&mc_head);
Index: sendbcast.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
retrieving revision 1.17
diff -u -r1.17 sendbcast.c
--- sendbcast.c	26 May 2004 01:40:12 -0000	1.17
+++ sendbcast.c	26 May 2004 16:57:22 -0000
@@ -150,7 +150,7 @@
  * @size: packet length
  * @importance: priority
  * mc_head: mc idenitity head
- * @Return: TIPC_OK: success
+ * @Return: 	 message data size: success
  *		 TIPC_FAILURE: fail
  *		 TIPC_CONGEST: congest
  */
@@ -214,7 +214,7 @@
 	INIT_LIST_HEAD(&mc_head);
 	res = nametbl_mc_translate(&mc_head, seq->type, seq->lower, seq->upper);
 	if (res == false)
-		return TIPC_ERR_NO_NAME;
+		return TIPC_FAILURE;
 	tipc_ownidentity(ref, &orig);
 	hdr = &this->publ.phdr;
 	msg_set_type(hdr, TIPC_MCAST_MSG);
@@ -271,8 +271,9 @@
   * send the buf using the bcastlinkset
   * Input parameter: buf: buf to be added to the outqueue
   *				  mc_head: mc identity head;
-  * Return: TIPC_OK: success
-  *		   other values: fail
+  *
+  * Return: 	message data size: 	success
+  *		other values: 		fail
   */
 
 int
@@ -409,6 +410,9 @@
  * blink_send_buf() is the 'full path' for messages, called from 
  * inside TIPC when the 'fast path' in tipc_send_buf/tipc_send_sections 
  * has failed, and from link_send()
+ *
+ * 	return message data size:	success
+ * 	       		   other:	failure
  */
 
 static int
@@ -420,6 +424,8 @@
 	uint imp = msg_tot_importance(msg);
 	uint queue_limit = this->queue_limit[imp];
 	uint max_packet = link_max_pkt(this);
+	uint dsz = msg_data_sz(msg);
+
 	msg_set_prevnode(msg, tipc_own_addr);
 
 	if (unlikely(queue_size >= queue_limit)) {
@@ -434,12 +440,11 @@
 			warn("Resetting %s, send queue full", this->name);
 			link_reset(this);
 		}
-		return TIPC_OK;
+		return dsz;
 	}
 
 	if (size > max_packet) {
-		link_send_long_buf(this, buf);
-		return TIPC_OK;
+		return link_send_long_buf(this, buf);
 	}
 
 	if (queue_size > this->stats.max_queue_sz)
@@ -454,22 +459,22 @@
 			bearer_schedule(this->bearer, this);
 			this->next_out = buf;
 		}
-		return TIPC_OK;
+		return dsz;
 	}
 
 	if (!this->next_out)
 		this->next_out = buf;
 	blink_add_to_outqueue(this, buf);
 	bearer_resolve_congestion(this->bearer, this);
-	return TIPC_OK;
+	return dsz;
 }
 
 /**
   * send out the broadcast buf using common link,add the buf to bcast out queue
   * Input : buf: buffer to be sent
   *		 this: link
-  * return: TIPC_OK: true
-  *		  other: failure
+  * return: 	message data size: 	success
+  *		other: 			failure
   */
 
 int
@@ -478,7 +483,7 @@
 
 	struct tipc_msg *msg = buf_msg(buf);
 	if (likely(this)) {
-		int res = TIPC_OK;
+		int res = msg_data_sz(msg);
 		if (likely(!link_congested(this))) {
 			if (likely(msg_size(msg) <= link_max_pkt(this))) {
 				if (likely(
@@ -501,7 +506,6 @@
 						bearer_schedule(this->bearer,
 								this);
 						this->next_out = buf;
-						res = TIPC_OK;
 						goto exit;
 					}
 				}
@@ -514,7 +518,7 @@
 	if (msg_destnode(msg) == tipc_own_addr)
 		return port_recv_msg(buf);
 	tipc_reject_msg(buf, TIPC_ERR_NO_NODE);
-	return TIPC_OK;
+	return TIPC_FAILURE;
 }
 
 /**
@@ -679,10 +683,11 @@
 
 /**
   * Tunel the buffer in the broadcast packet and  retransmit it
-  * Input parameters: this: link
-  * 				    buf: buffer to be sent
-  *				    last_seq:seqno
-  * return			: void
+  * Input parameters: 	this: link
+  * 			 buf: buffer to be sent
+  *		    last_seq:seqno
+  *
+  * return		    : void
   */
 void
 bcast_link_retransmit(struct link *this, struct sk_buff *buf, uint lastseq)

-- 
Mark Haverkamp <ma...@os...>

RE: [Tipc-discussion] patch bcast fix in nameseq_deliver

[Ling, X. <xia...@in...>]

It's good fix. I've checked in. Also add some code clean up.
For blink_send_buf_fast's return value, it do has the problem need to be =
fixed.

>-----Original Message-----
>From: tip...@li...=20
>[mailto:tip...@li...] On Behalf=20
>Of Daniel McNeil
>Sent: 2004=C4=EA5=D4=C226=C8=D5 5:28
>To: tipc
>Subject: [Tipc-discussion] patch bcast fix in nameseq_deliver
>
>Jon,
>
>When testing multicast and having 2 processes on the same node
>running my membership code, one process was not getting messages.
>I found another place where getting the number of bytes sent was
>being treated as an error.
>
>Here's the patch to fix nameseq_deliver():
>
>Index: recvbcast.c
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>RCS file: /cvsroot/tipc/source/unstable/net/tipc/recvbcast.c,v
>retrieving revision 1.18
>diff -u -b -B -p -u -r1.18 recvbcast.c
>--- recvbcast.c	5 May 2004 19:09:03 -0000	1.18
>+++ recvbcast.c	25 May 2004 20:30:53 -0000
>@@ -446,6 +446,7 @@ nameseq_deliver(struct sk_buff *buf, str
> 	struct list_head *pos;
> 	struct mc_identity *mid;
> 	int res =3D TIPC_OK;
>+	int sz =3D msg_data_sz(buf_msg(buf));
>=20
> 	dbg("nameseq_deliver\n");
> 	list_for_each(pos, mc_head) {
>@@ -458,7 +459,7 @@ nameseq_deliver(struct sk_buff *buf, str
> 			msg_set_destport(buf_msg(copymsg), mid->port);
> 			if (port) {
> 				res =3D port_recv_msg(copymsg);
>-				if (res)
>+				if (res !=3D sz)
> 					break;
> 			}
> 		}
>
>
>
>It also looks like blink_send_buf_fast() should be returning the=20
>number of bytes sent.  It sometimes does and sometimes returns TIPC_OK.
>Mark and I are still looking at it.
>
>Daniel
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market...=20
>Oracle 10g.=20
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
>_______________________________________________
>TIPC-discussion mailing list
>TIP...@li...
>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>

Re: [Tipc-discussion] patch bcast fix in nameseq_deliver

[Jon M. <jon...@er...>]

It looks ok to me. Unless Ling has some objections, you can
check it in.

/jon

Daniel McNeil wrote:

>Jon,
>
>When testing multicast and having 2 processes on the same node
>running my membership code, one process was not getting messages.
>I found another place where getting the number of bytes sent was
>being treated as an error.
>
>Here's the patch to fix nameseq_deliver():
>
>Index: recvbcast.c
>===================================================================
>RCS file: /cvsroot/tipc/source/unstable/net/tipc/recvbcast.c,v
>retrieving revision 1.18
>diff -u -b -B -p -u -r1.18 recvbcast.c
>--- recvbcast.c	5 May 2004 19:09:03 -0000	1.18
>+++ recvbcast.c	25 May 2004 20:30:53 -0000
>@@ -446,6 +446,7 @@ nameseq_deliver(struct sk_buff *buf, str
> 	struct list_head *pos;
> 	struct mc_identity *mid;
> 	int res = TIPC_OK;
>+	int sz = msg_data_sz(buf_msg(buf));
> 
> 	dbg("nameseq_deliver\n");
> 	list_for_each(pos, mc_head) {
>@@ -458,7 +459,7 @@ nameseq_deliver(struct sk_buff *buf, str
> 			msg_set_destport(buf_msg(copymsg), mid->port);
> 			if (port) {
> 				res = port_recv_msg(copymsg);
>-				if (res)
>+				if (res != sz)
> 					break;
> 			}
> 		}
>
>
>
>It also looks like blink_send_buf_fast() should be returning the 
>number of bytes sent.  It sometimes does and sometimes returns TIPC_OK.
>Mark and I are still looking at it.
>
>Daniel
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>TIPC-discussion mailing list
>TIP...@li...
>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>  
>

[Tipc-discussion] patch bcast fix in nameseq_deliver

[Daniel M. <da...@os...>]

Jon,

When testing multicast and having 2 processes on the same node
running my membership code, one process was not getting messages.
I found another place where getting the number of bytes sent was
being treated as an error.

Here's the patch to fix nameseq_deliver():

Index: recvbcast.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/recvbcast.c,v
retrieving revision 1.18
diff -u -b -B -p -u -r1.18 recvbcast.c
--- recvbcast.c	5 May 2004 19:09:03 -0000	1.18
+++ recvbcast.c	25 May 2004 20:30:53 -0000
@@ -446,6 +446,7 @@ nameseq_deliver(struct sk_buff *buf, str
 	struct list_head *pos;
 	struct mc_identity *mid;
 	int res = TIPC_OK;
+	int sz = msg_data_sz(buf_msg(buf));
 
 	dbg("nameseq_deliver\n");
 	list_for_each(pos, mc_head) {
@@ -458,7 +459,7 @@ nameseq_deliver(struct sk_buff *buf, str
 			msg_set_destport(buf_msg(copymsg), mid->port);
 			if (port) {
 				res = port_recv_msg(copymsg);
-				if (res)
+				if (res != sz)
 					break;
 			}
 		}



It also looks like blink_send_buf_fast() should be returning the 
number of bytes sent.  It sometimes does and sometimes returns TIPC_OK.
Mark and I are still looking at it.

Daniel

[Tipc-discussion] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

RE: [Tipc-discussion] Yet another version checked in

[Ling, X. <xia...@in...>]

I'm now engaged with other projects, but I'll keep on tracking TIPC and =
work for bug fixing if needed.

>-----Original Message-----
>From: tip...@li...=20
>[mailto:tip...@li...] On Behalf=20
>Of Jon Maloy
>Sent: 2004=C4=EA5=D4=C222=C8=D5 6:57
>To: Nick Yin
>Cc: Guo, Min; ma...@os...; da...@os...;=20
>tip...@li...
>Subject: Re: [Tipc-discussion] Yet another version checked in
>
>You are welcome.
>Does this mean that Guo and Ling have stopped working with
>TIPC (they have been silent for a while), or do they still
>feel responsible for the broadcast code ?
>
>Regards /jon
>
>Regards /jon
>
>Nick Yin wrote:
>
>> Guo Min,
>>
>> Thank you for your introduction! Jon and Mark, nice to meet=20
>you here,=20
>> it's my pleasure to do some job for TIPC's validtion. Hope you can=20
>> give me some support in the future. Thank you all in advance!
>>
>> Thanks,
>>
>> Yin Hu (Nick)
>>
>>> From: "Guo, Min" <mi...@in...>
>>> To: "Mark Haverkamp" <ma...@os...>, "Jon Maloy"=20
>>> <jon...@er...>
>>> CC: "Daniel McNeil" <da...@os...>,   "tipc"=20
>>> <tip...@li...>
>>> Subject: RE: [Tipc-discussion] Yet another version checked in
>>> Date: Fri, 21 May 2004 08:51:24 +0800
>>>
>>> The patch is OK for me! you can apply it by yourself.
>>> For  the blink_remove bug,can you reproduce the bug and=20
>send us the back
>>> trace log?
>>>
>>> Another thing is YinHu, who is now a intern in Intel,will=20
>contribute the
>>> TIPC validation in the future,
>>> wish he can get help from you all!
>>>
>>> Thanks
>>> Guo Min
>>>
>>> tip...@li... wrote:
>>> > On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:
>>> >> The last thing I did before the port_lock changes was to add
>>> >> a device notifier in eth_media, and a "tipc_block_bearer()"
>>> >> function to handle this. I tested this with an  "ifconfig eth1
>>> >> down/up" (I run dual links most of the time) during traffic, and
>>> >> this worked fine, but when I thereafter removed the=20
>module  I got a
>>> >> crash
>>> >> in bcast.c/blink_remove(), - a NULL pointer access.
>>> >>
>>> >> I corrected this (I believed) and tested it, but it seems like I
>>> >> have still introduced some problem here.
>>> >>
>>> >> Maybe Guo or Ling can say more about this ? Pay special
>>> >> attention to the flag "blocked" in the bearer, if this gets stuck
>>> >>  with with the wrong value the traffic will never restart.
>>> >>
>>> >
>>> > Daniel and I sprinkled a few printks around and found an error in
>>> > tipc_forward_buf2nameseq.  The main problem was that the=20
>result from
>>> > bcast_port_recv is the message data size but was being checked for
>>> > non-zero to be an error.  Also the result was only being
>>> > checked for the
>>> > local delivery, and the prev_destnode was being reset to=20
>zero inside
>>> > the loop defeating its purpose.  Included is a patch that=20
>works for
>>> > us.
>>> >
>>> > One other thing, since tipc_forward_buf2nameseq returns the
>>> > message data
>>> > size, that means that tipc_multicast returns the same.
>>> >
>>> > cvs diff -u sendbcast.c
>>> > Index: sendbcast.c
>>> >=20
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> > RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
>>> > retrieving revision 1.15 diff -u -r1.15 sendbcast.c
>>> > --- sendbcast.c    6 May 2004 15:35:31 -0000    1.15
>>> > +++ sendbcast.c    20 May 2004 16:08:03 -0000
>>> > @@ -167,18 +167,20 @@
>>> >  {
>>> >      struct port *this =3D (struct port *) ref_deref(ref); =20
>    uint res
>>> =3D 0;
>>> > +    int dsz;
>>> >      struct tipc_msg *m;
>>> >      struct mc_identity *mid =3D NULL;
>>> >      struct list_head *pos;
>>> >      struct sk_buff *copybuf;
>>> >      tipc_net_addr_t prev_destnode;
>>> >
>>> > +    dsz =3D msg_data_sz(buf_msg(buf));
>>> >      m =3D &this->publ.phdr;
>>> >      if (importance <=3D 3)
>>> >          msg_set_importance(m, importance);
>>> >
>>> > +    prev_destnode =3D 0;
>>> >      list_for_each(pos, mc_head) {
>>> > -        prev_destnode =3D 0;
>>> >          mid =3D list_entry(pos, struct mc_identity, list);
>>> >          if (mid !=3D NULL && (prev_destnode !=3D mid->node)) {
>>> >              prev_destnode =3D mid->node;
>>> > @@ -188,9 +190,9 @@
>>> >                  res =3D
>>> > tipc_send_buf_fast(copybuf, mid->node);
>>> >              } else {
>>> >                  res =3D bcast_port_recv(copybuf);
>>> > -                if (res !=3D 0)
>>> > -                    break;
>>> >              }
>>> > +            if (res !=3D dsz)
>>> > +                break;
>>> >          }
>>> >      }
>>> >      buf_safe_discard(buf);
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: Oracle 10g
>>> Get certified on the hottest thing ever to hit the=20
>market... Oracle 10g.
>>> Take an Oracle 10g class now, and we'll give you the exam FREE.
>>> http://ads.osdn.com/?ad_id149&alloc_id?6&op=3Dclick
>>> _______________________________________________
>>> TIPC-discussion mailing list
>>> TIP...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>
>>
>> _________________________________________________________________
>> Protect your PC - get McAfee.com VirusScan Online=20
>> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market...=20
>Oracle 10g.=20
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
>_______________________________________________
>TIPC-discussion mailing list
>TIP...@li...
>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>

Re: [Tipc-discussion] Yet another version checked in

[Nick Y. <ni...@ho...>]

Jon,

Sorry, i don't how to reply you. I think Guo and Ling will give you a 
satisfied answer ASAP.

Have a nice weekend!

Best regards,

Nick

>From: Jon Maloy <jon...@er...>
>To: Nick Yin <ni...@ho...>
>CC: mi...@in..., ma...@os..., da...@os...,        
>tip...@li...
>Subject: Re: [Tipc-discussion] Yet another version checked in
>Date: Fri, 21 May 2004 18:56:54 -0400
>
>You are welcome.
>Does this mean that Guo and Ling have stopped working with
>TIPC (they have been silent for a while), or do they still
>feel responsible for the broadcast code ?
>
>Regards /jon
>
>Regards /jon
>
>Nick Yin wrote:
>
>>Guo Min,
>>
>>Thank you for your introduction! Jon and Mark, nice to meet you here, it's 
>>my pleasure to do some job for TIPC's validtion. Hope you can give me some 
>>support in the future. Thank you all in advance!
>>
>>Thanks,
>>
>>Yin Hu (Nick)
>>
>>>From: "Guo, Min" <mi...@in...>
>>>To: "Mark Haverkamp" <ma...@os...>, "Jon Maloy" 
>>><jon...@er...>
>>>CC: "Daniel McNeil" <da...@os...>,   "tipc" 
>>><tip...@li...>
>>>Subject: RE: [Tipc-discussion] Yet another version checked in
>>>Date: Fri, 21 May 2004 08:51:24 +0800
>>>
>>>The patch is OK for me! you can apply it by yourself.
>>>For  the blink_remove bug,can you reproduce the bug and send us the back
>>>trace log?
>>>
>>>Another thing is YinHu, who is now a intern in Intel,will contribute the
>>>TIPC validation in the future,
>>>wish he can get help from you all!
>>>
>>>Thanks
>>>Guo Min
>>>
>>>tip...@li... wrote:
>>> > On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:
>>> >> The last thing I did before the port_lock changes was to add
>>> >> a device notifier in eth_media, and a "tipc_block_bearer()"
>>> >> function to handle this. I tested this with an  "ifconfig eth1
>>> >> down/up" (I run dual links most of the time) during traffic, and
>>> >> this worked fine, but when I thereafter removed the module  I got a
>>> >> crash
>>> >> in bcast.c/blink_remove(), - a NULL pointer access.
>>> >>
>>> >> I corrected this (I believed) and tested it, but it seems like I
>>> >> have still introduced some problem here.
>>> >>
>>> >> Maybe Guo or Ling can say more about this ? Pay special
>>> >> attention to the flag "blocked" in the bearer, if this gets stuck
>>> >>  with with the wrong value the traffic will never restart.
>>> >>
>>> >
>>> > Daniel and I sprinkled a few printks around and found an error in
>>> > tipc_forward_buf2nameseq.  The main problem was that the result from
>>> > bcast_port_recv is the message data size but was being checked for
>>> > non-zero to be an error.  Also the result was only being
>>> > checked for the
>>> > local delivery, and the prev_destnode was being reset to zero inside
>>> > the loop defeating its purpose.  Included is a patch that works for
>>> > us.
>>> >
>>> > One other thing, since tipc_forward_buf2nameseq returns the
>>> > message data
>>> > size, that means that tipc_multicast returns the same.
>>> >
>>> > cvs diff -u sendbcast.c
>>> > Index: sendbcast.c
>>> > ===================================================================
>>> > RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
>>> > retrieving revision 1.15 diff -u -r1.15 sendbcast.c
>>> > --- sendbcast.c    6 May 2004 15:35:31 -0000    1.15
>>> > +++ sendbcast.c    20 May 2004 16:08:03 -0000
>>> > @@ -167,18 +167,20 @@
>>> >  {
>>> >      struct port *this = (struct port *) ref_deref(ref);      uint res
>>>= 0;
>>> > +    int dsz;
>>> >      struct tipc_msg *m;
>>> >      struct mc_identity *mid = NULL;
>>> >      struct list_head *pos;
>>> >      struct sk_buff *copybuf;
>>> >      tipc_net_addr_t prev_destnode;
>>> >
>>> > +    dsz = msg_data_sz(buf_msg(buf));
>>> >      m = &this->publ.phdr;
>>> >      if (importance <= 3)
>>> >          msg_set_importance(m, importance);
>>> >
>>> > +    prev_destnode = 0;
>>> >      list_for_each(pos, mc_head) {
>>> > -        prev_destnode = 0;
>>> >          mid = list_entry(pos, struct mc_identity, list);
>>> >          if (mid != NULL && (prev_destnode != mid->node)) {
>>> >              prev_destnode = mid->node;
>>> > @@ -188,9 +190,9 @@
>>> >                  res =
>>> > tipc_send_buf_fast(copybuf, mid->node);
>>> >              } else {
>>> >                  res = bcast_port_recv(copybuf);
>>> > -                if (res != 0)
>>> > -                    break;
>>> >              }
>>> > +            if (res != dsz)
>>> > +                break;
>>> >          }
>>> >      }
>>> >      buf_safe_discard(buf);
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: Oracle 10g
>>>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>>http://ads.osdn.com/?ad_id149&alloc_id?6&op=click
>>>_______________________________________________
>>>TIPC-discussion mailing list
>>>TIP...@li...
>>>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>
>>
>>_________________________________________________________________
>>Protect your PC - get McAfee.com VirusScan Online 
>>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Tipc-discussion] Yet another version checked in

[Jon M. <jon...@er...>]

You are welcome.
Does this mean that Guo and Ling have stopped working with
TIPC (they have been silent for a while), or do they still
feel responsible for the broadcast code ?

Regards /jon

Regards /jon

Nick Yin wrote:

> Guo Min,
>
> Thank you for your introduction! Jon and Mark, nice to meet you here, 
> it's my pleasure to do some job for TIPC's validtion. Hope you can 
> give me some support in the future. Thank you all in advance!
>
> Thanks,
>
> Yin Hu (Nick)
>
>> From: "Guo, Min" <mi...@in...>
>> To: "Mark Haverkamp" <ma...@os...>, "Jon Maloy" 
>> <jon...@er...>
>> CC: "Daniel McNeil" <da...@os...>,   "tipc" 
>> <tip...@li...>
>> Subject: RE: [Tipc-discussion] Yet another version checked in
>> Date: Fri, 21 May 2004 08:51:24 +0800
>>
>> The patch is OK for me! you can apply it by yourself.
>> For  the blink_remove bug,can you reproduce the bug and send us the back
>> trace log?
>>
>> Another thing is YinHu, who is now a intern in Intel,will contribute the
>> TIPC validation in the future,
>> wish he can get help from you all!
>>
>> Thanks
>> Guo Min
>>
>> tip...@li... wrote:
>> > On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:
>> >> The last thing I did before the port_lock changes was to add
>> >> a device notifier in eth_media, and a "tipc_block_bearer()"
>> >> function to handle this. I tested this with an  "ifconfig eth1
>> >> down/up" (I run dual links most of the time) during traffic, and
>> >> this worked fine, but when I thereafter removed the module  I got a
>> >> crash
>> >> in bcast.c/blink_remove(), - a NULL pointer access.
>> >>
>> >> I corrected this (I believed) and tested it, but it seems like I
>> >> have still introduced some problem here.
>> >>
>> >> Maybe Guo or Ling can say more about this ? Pay special
>> >> attention to the flag "blocked" in the bearer, if this gets stuck
>> >>  with with the wrong value the traffic will never restart.
>> >>
>> >
>> > Daniel and I sprinkled a few printks around and found an error in
>> > tipc_forward_buf2nameseq.  The main problem was that the result from
>> > bcast_port_recv is the message data size but was being checked for
>> > non-zero to be an error.  Also the result was only being
>> > checked for the
>> > local delivery, and the prev_destnode was being reset to zero inside
>> > the loop defeating its purpose.  Included is a patch that works for
>> > us.
>> >
>> > One other thing, since tipc_forward_buf2nameseq returns the
>> > message data
>> > size, that means that tipc_multicast returns the same.
>> >
>> > cvs diff -u sendbcast.c
>> > Index: sendbcast.c
>> > ===================================================================
>> > RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
>> > retrieving revision 1.15 diff -u -r1.15 sendbcast.c
>> > --- sendbcast.c    6 May 2004 15:35:31 -0000    1.15
>> > +++ sendbcast.c    20 May 2004 16:08:03 -0000
>> > @@ -167,18 +167,20 @@
>> >  {
>> >      struct port *this = (struct port *) ref_deref(ref);      uint res
>> = 0;
>> > +    int dsz;
>> >      struct tipc_msg *m;
>> >      struct mc_identity *mid = NULL;
>> >      struct list_head *pos;
>> >      struct sk_buff *copybuf;
>> >      tipc_net_addr_t prev_destnode;
>> >
>> > +    dsz = msg_data_sz(buf_msg(buf));
>> >      m = &this->publ.phdr;
>> >      if (importance <= 3)
>> >          msg_set_importance(m, importance);
>> >
>> > +    prev_destnode = 0;
>> >      list_for_each(pos, mc_head) {
>> > -        prev_destnode = 0;
>> >          mid = list_entry(pos, struct mc_identity, list);
>> >          if (mid != NULL && (prev_destnode != mid->node)) {
>> >              prev_destnode = mid->node;
>> > @@ -188,9 +190,9 @@
>> >                  res =
>> > tipc_send_buf_fast(copybuf, mid->node);
>> >              } else {
>> >                  res = bcast_port_recv(copybuf);
>> > -                if (res != 0)
>> > -                    break;
>> >              }
>> > +            if (res != dsz)
>> > +                break;
>> >          }
>> >      }
>> >      buf_safe_discard(buf);
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 10g.
>> Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id149&alloc_id?6&op=click
>> _______________________________________________
>> TIPC-discussion mailing list
>> TIP...@li...
>> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online 
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: [Tipc-discussion] Yet another version checked in

[Jon M. <jon...@er...>]

Guo,
It was an obvious NULL-pointer error (in blinkset_remove, not 
blink_remove as I wrote). I fixed this, and everything works fine; 
it does not seem related to the problem Daniel found.  I don't
have a dump, but here is the change I did.

<  * $Id: bcast.c,v 1.23 2004/05/19 17:47:16 jonmaloy Exp $
<  * $Id: bcast.c,v 1.23 2004/05/19 17:47:16 jonmaloy Exp $
---
>  * $Id: bcast.c,v 1.22 2004/05/07 22:17:26 jonmaloy Exp $
>  * $Id: bcast.c,v 1.22 2004/05/07 22:17:26 jonmaloy Exp $
46,48d45
<  * Revision 1.23  2004/05/19 17:47:16  jonmaloy
<  * Fixed NULL-pointer bug in blinkset_remove
<  *
751,752d747
<                 if (linkset[i] == NULL)
<                         continue;

Thanks /jon

Guo, Min wrote:


The patch is OK for me! you can apply it by yourself.

For  the blink_remove bug,can you reproduce the bug and send us the back

trace log?



Another thing is YinHu, who is now a intern in Intel,will contribute the

TIPC validation in the future,

wish he can get help from you all!



Thanks

Guo Min



tip...@li...
<mailto:tip...@li...>  wrote:

  

On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:

    

The last thing I did before the port_lock changes was to add

a device notifier in eth_media, and a "tipc_block_bearer()"

function to handle this. I tested this with an  "ifconfig eth1

down/up" (I run dual links most of the time) during traffic, and

this worked fine, but when I thereafter removed the module  I got a

crash 

in bcast.c/blink_remove(), - a NULL pointer access.



I corrected this (I believed) and tested it, but it seems like I

have still introduced some problem here.



Maybe Guo or Ling can say more about this ? Pay special

attention to the flag "blocked" in the bearer, if this gets stuck

 with with the wrong value the traffic will never restart.



      

Daniel and I sprinkled a few printks around and found an error in

tipc_forward_buf2nameseq.  The main problem was that the result from

bcast_port_recv is the message data size but was being checked for

non-zero to be an error.  Also the result was only being

checked for the

local delivery, and the prev_destnode was being reset to zero inside

the loop defeating its purpose.  Included is a patch that works for

us. 



One other thing, since tipc_forward_buf2nameseq returns the

message data

size, that means that tipc_multicast returns the same.



cvs diff -u sendbcast.c

Index: sendbcast.c

===================================================================

RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v

retrieving revision 1.15 diff -u -r1.15 sendbcast.c

--- sendbcast.c	6 May 2004 15:35:31 -0000	1.15

+++ sendbcast.c	20 May 2004 16:08:03 -0000

@@ -167,18 +167,20 @@

 {

 	struct port *this = (struct port *) ref_deref(ref);  	uint res

    

= 0;

  

+	int dsz;

 	struct tipc_msg *m;

 	struct mc_identity *mid = NULL;

 	struct list_head *pos;

 	struct sk_buff *copybuf;

 	tipc_net_addr_t prev_destnode;



+	dsz = msg_data_sz(buf_msg(buf));

 	m = &this->publ.phdr;

 	if (importance <= 3)

 		msg_set_importance(m, importance);



+	prev_destnode = 0;

 	list_for_each(pos, mc_head) {

-		prev_destnode = 0;

 		mid = list_entry(pos, struct mc_identity, list);

 		if (mid != NULL && (prev_destnode != mid->node)) {

 			prev_destnode = mid->node;

@@ -188,9 +190,9 @@

 				res =

tipc_send_buf_fast(copybuf, mid->node);

 			} else {

 				res = bcast_port_recv(copybuf);

-				if (res != 0)

-					break;

 			}

+			if (res != dsz)

+				break;

 		}

 	}

 	buf_safe_discard(buf)

;

  

RE: [Tipc-discussion] Yet another version checked in

[Nick Y. <ni...@ho...>]

Guo Min,

Thank you for your introduction! Jon and Mark, nice to meet you here, it's 
my pleasure to do some job for TIPC's validtion. Hope you can give me some 
support in the future. Thank you all in advance!

Thanks,

Yin Hu (Nick)

>From: "Guo, Min" <mi...@in...>
>To: "Mark Haverkamp" <ma...@os...>, "Jon Maloy" <jon...@er...>
>CC: "Daniel McNeil" <da...@os...>,   "tipc" 
><tip...@li...>
>Subject: RE: [Tipc-discussion] Yet another version checked in
>Date: Fri, 21 May 2004 08:51:24 +0800
>
>The patch is OK for me! you can apply it by yourself.
>For  the blink_remove bug,can you reproduce the bug and send us the back
>trace log?
>
>Another thing is YinHu, who is now a intern in Intel,will contribute the
>TIPC validation in the future,
>wish he can get help from you all!
>
>Thanks
>Guo Min
>
>tip...@li... wrote:
> > On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:
> >> The last thing I did before the port_lock changes was to add
> >> a device notifier in eth_media, and a "tipc_block_bearer()"
> >> function to handle this. I tested this with an  "ifconfig eth1
> >> down/up" (I run dual links most of the time) during traffic, and
> >> this worked fine, but when I thereafter removed the module  I got a
> >> crash
> >> in bcast.c/blink_remove(), - a NULL pointer access.
> >>
> >> I corrected this (I believed) and tested it, but it seems like I
> >> have still introduced some problem here.
> >>
> >> Maybe Guo or Ling can say more about this ? Pay special
> >> attention to the flag "blocked" in the bearer, if this gets stuck
> >>  with with the wrong value the traffic will never restart.
> >>
> >
> > Daniel and I sprinkled a few printks around and found an error in
> > tipc_forward_buf2nameseq.  The main problem was that the result from
> > bcast_port_recv is the message data size but was being checked for
> > non-zero to be an error.  Also the result was only being
> > checked for the
> > local delivery, and the prev_destnode was being reset to zero inside
> > the loop defeating its purpose.  Included is a patch that works for
> > us.
> >
> > One other thing, since tipc_forward_buf2nameseq returns the
> > message data
> > size, that means that tipc_multicast returns the same.
> >
> > cvs diff -u sendbcast.c
> > Index: sendbcast.c
> > ===================================================================
> > RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
> > retrieving revision 1.15 diff -u -r1.15 sendbcast.c
> > --- sendbcast.c	6 May 2004 15:35:31 -0000	1.15
> > +++ sendbcast.c	20 May 2004 16:08:03 -0000
> > @@ -167,18 +167,20 @@
> >  {
> >  	struct port *this = (struct port *) ref_deref(ref);  	uint res
>= 0;
> > +	int dsz;
> >  	struct tipc_msg *m;
> >  	struct mc_identity *mid = NULL;
> >  	struct list_head *pos;
> >  	struct sk_buff *copybuf;
> >  	tipc_net_addr_t prev_destnode;
> >
> > +	dsz = msg_data_sz(buf_msg(buf));
> >  	m = &this->publ.phdr;
> >  	if (importance <= 3)
> >  		msg_set_importance(m, importance);
> >
> > +	prev_destnode = 0;
> >  	list_for_each(pos, mc_head) {
> > -		prev_destnode = 0;
> >  		mid = list_entry(pos, struct mc_identity, list);
> >  		if (mid != NULL && (prev_destnode != mid->node)) {
> >  			prev_destnode = mid->node;
> > @@ -188,9 +190,9 @@
> >  				res =
> > tipc_send_buf_fast(copybuf, mid->node);
> >  			} else {
> >  				res = bcast_port_recv(copybuf);
> > -				if (res != 0)
> > -					break;
> >  			}
> > +			if (res != dsz)
> > +				break;
> >  		}
> >  	}
> >  	buf_safe_discard(buf);
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id149&alloc_id?6&op=click
>_______________________________________________
>TIPC-discussion mailing list
>TIP...@li...
>https://lists.sourceforge.net/lists/listinfo/tipc-discussion

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

RE: [Tipc-discussion] Yet another version checked in

[Guo, M. <mi...@in...>]

The patch is OK for me! you can apply it by yourself.
For  the blink_remove bug,can you reproduce the bug and send us the back
trace log?

Another thing is YinHu, who is now a intern in Intel,will contribute the
TIPC validation in the future,
wish he can get help from you all!

Thanks
Guo Min

tip...@li... wrote:
> On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:
>> The last thing I did before the port_lock changes was to add
>> a device notifier in eth_media, and a "tipc_block_bearer()"
>> function to handle this. I tested this with an  "ifconfig eth1
>> down/up" (I run dual links most of the time) during traffic, and
>> this worked fine, but when I thereafter removed the module  I got a
>> crash=20
>> in bcast.c/blink_remove(), - a NULL pointer access.
>>=20
>> I corrected this (I believed) and tested it, but it seems like I
>> have still introduced some problem here.
>>=20
>> Maybe Guo or Ling can say more about this ? Pay special
>> attention to the flag "blocked" in the bearer, if this gets stuck
>>  with with the wrong value the traffic will never restart.
>>=20
>=20
> Daniel and I sprinkled a few printks around and found an error in
> tipc_forward_buf2nameseq.  The main problem was that the result from
> bcast_port_recv is the message data size but was being checked for
> non-zero to be an error.  Also the result was only being
> checked for the
> local delivery, and the prev_destnode was being reset to zero inside
> the loop defeating its purpose.  Included is a patch that works for
> us.=20
>=20
> One other thing, since tipc_forward_buf2nameseq returns the
> message data
> size, that means that tipc_multicast returns the same.
>=20
> cvs diff -u sendbcast.c
> Index: sendbcast.c
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
> retrieving revision 1.15 diff -u -r1.15 sendbcast.c
> --- sendbcast.c	6 May 2004 15:35:31 -0000	1.15
> +++ sendbcast.c	20 May 2004 16:08:03 -0000
> @@ -167,18 +167,20 @@
>  {
>  	struct port *this =3D (struct port *) ref_deref(ref);  	uint res
=3D 0;
> +	int dsz;
>  	struct tipc_msg *m;
>  	struct mc_identity *mid =3D NULL;
>  	struct list_head *pos;
>  	struct sk_buff *copybuf;
>  	tipc_net_addr_t prev_destnode;
>=20
> +	dsz =3D msg_data_sz(buf_msg(buf));
>  	m =3D &this->publ.phdr;
>  	if (importance <=3D 3)
>  		msg_set_importance(m, importance);
>=20
> +	prev_destnode =3D 0;
>  	list_for_each(pos, mc_head) {
> -		prev_destnode =3D 0;
>  		mid =3D list_entry(pos, struct mc_identity, list);
>  		if (mid !=3D NULL && (prev_destnode !=3D mid->node)) {
>  			prev_destnode =3D mid->node;
> @@ -188,9 +190,9 @@
>  				res =3D
> tipc_send_buf_fast(copybuf, mid->node);
>  			} else {
>  				res =3D bcast_port_recv(copybuf);
> -				if (res !=3D 0)
> -					break;
>  			}
> +			if (res !=3D dsz)
> +				break;
>  		}
>  	}
>  	buf_safe_discard(buf);

Re: [Tipc-discussion] Yet another version checked in

[Jon M. <jon...@er...>]

This is what I meant. I can not see the relation between
my changes and the multicast problem. Anyway, as long
as it works I am happy.

/jon

Daniel McNeil wrote:


On Thu, 2004-05-20 at 10:00, Jon Maloy wrote:

  

Sounds good. Does this mean that the problem from yesterday

is solved? If so, it puzzles me that this problem showed

up now, after my seemingly unrelated changes, and not

earlier.



/jon

    



This fixes the multicast problem.  Mark is still seeing a problem

when running 64 processes.



Daniel

  

Re: [Tipc-discussion] Yet another version checked in

[Daniel M. <da...@os...>]

On Thu, 2004-05-20 at 10:00, Jon Maloy wrote:
> Sounds good. Does this mean that the problem from yesterday
> is solved? If so, it puzzles me that this problem showed
> up now, after my seemingly unrelated changes, and not
> earlier.
> 
> /jon

This fixes the multicast problem.  Mark is still seeing a problem
when running 64 processes.

Daniel

Re: [Tipc-discussion] Yet another version checked in

[Jon M. <jon...@er...>]

Sounds good. Does this mean that the problem from yesterday
is solved? If so, it puzzles me that this problem showed
up now, after my seemingly unrelated changes, and not
earlier.

/jon

Mark Haverkamp wrote:


On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:

  

The last thing I did before the port_lock changes was to add

a device notifier in eth_media, and a "tipc_block_bearer()"

function to handle this. I tested this with an  "ifconfig eth1

down/up" 

(I run dual links most of the time) during traffic, and this worked

fine, but when I thereafter removed the module  I got a crash

in bcast.c/blink_remove(), - a NULL pointer access. 



I corrected this (I believed) and tested it, but it seems like I 

have still introduced some problem here. 



Maybe Guo or Ling can say more about this ? Pay special

attention to the flag "blocked" in the bearer, if this gets stuck with

 with the wrong value the traffic will never restart. 



    



Daniel and I sprinkled a few printks around and found an error in

tipc_forward_buf2nameseq.  The main problem was that the result from

bcast_port_recv is the message data size but was being checked for

non-zero to be an error.  Also the result was only being checked for the

local delivery, and the prev_destnode was being reset to zero inside the

loop defeating its purpose.  Included is a patch that works for us.



One other thing, since tipc_forward_buf2nameseq returns the message data

size, that means that tipc_multicast returns the same.



cvs diff -u sendbcast.c

Index: sendbcast.c

===================================================================

RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v

retrieving revision 1.15

diff -u -r1.15 sendbcast.c

--- sendbcast.c	6 May 2004 15:35:31 -0000	1.15

+++ sendbcast.c	20 May 2004 16:08:03 -0000

@@ -167,18 +167,20 @@

 {

 	struct port *this = (struct port *) ref_deref(ref);

 	uint res = 0;

+	int dsz;

 	struct tipc_msg *m;

 	struct mc_identity *mid = NULL;

 	struct list_head *pos;

 	struct sk_buff *copybuf;

 	tipc_net_addr_t prev_destnode;

 

+	dsz = msg_data_sz(buf_msg(buf));

 	m = &this->publ.phdr;

 	if (importance <= 3)

 		msg_set_importance(m, importance);

 

+	prev_destnode = 0;

 	list_for_each(pos, mc_head) {

-		prev_destnode = 0;

 		mid = list_entry(pos, struct mc_identity, list);

 		if (mid != NULL && (prev_destnode != mid->node)) {

 			prev_destnode = mid->node;

@@ -188,9 +190,9 @@

 				res = tipc_send_buf_fast(copybuf,
mid->node);

 			} else {

 				res = bcast_port_recv(copybuf);

-				if (res != 0)

-					break;

 			}

+			if (res != dsz)

+				break;

 		}

 	}

 	buf_safe_discard(buf);



  

Re: [Tipc-discussion] Yet another version checked in

[Mark H. <ma...@os...>]

On Wed, 2004-05-19 at 16:54, Jon Maloy wrote:
> The last thing I did before the port_lock changes was to add
> a device notifier in eth_media, and a "tipc_block_bearer()"
> function to handle this. I tested this with an  "ifconfig eth1
> down/up" 
> (I run dual links most of the time) during traffic, and this worked
> fine, but when I thereafter removed the module  I got a crash
> in bcast.c/blink_remove(), - a NULL pointer access. 
> 
> I corrected this (I believed) and tested it, but it seems like I 
> have still introduced some problem here. 
> 
> Maybe Guo or Ling can say more about this ? Pay special
> attention to the flag "blocked" in the bearer, if this gets stuck with
>  with the wrong value the traffic will never restart. 
> 

Daniel and I sprinkled a few printks around and found an error in
tipc_forward_buf2nameseq.  The main problem was that the result from
bcast_port_recv is the message data size but was being checked for
non-zero to be an error.  Also the result was only being checked for the
local delivery, and the prev_destnode was being reset to zero inside the
loop defeating its purpose.  Included is a patch that works for us.

One other thing, since tipc_forward_buf2nameseq returns the message data
size, that means that tipc_multicast returns the same.

cvs diff -u sendbcast.c
Index: sendbcast.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
retrieving revision 1.15
diff -u -r1.15 sendbcast.c
--- sendbcast.c	6 May 2004 15:35:31 -0000	1.15
+++ sendbcast.c	20 May 2004 16:08:03 -0000
@@ -167,18 +167,20 @@
 {
 	struct port *this = (struct port *) ref_deref(ref);
 	uint res = 0;
+	int dsz;
 	struct tipc_msg *m;
 	struct mc_identity *mid = NULL;
 	struct list_head *pos;
 	struct sk_buff *copybuf;
 	tipc_net_addr_t prev_destnode;
 
+	dsz = msg_data_sz(buf_msg(buf));
 	m = &this->publ.phdr;
 	if (importance <= 3)
 		msg_set_importance(m, importance);
 
+	prev_destnode = 0;
 	list_for_each(pos, mc_head) {
-		prev_destnode = 0;
 		mid = list_entry(pos, struct mc_identity, list);
 		if (mid != NULL && (prev_destnode != mid->node)) {
 			prev_destnode = mid->node;
@@ -188,9 +190,9 @@
 				res = tipc_send_buf_fast(copybuf, mid->node);
 			} else {
 				res = bcast_port_recv(copybuf);
-				if (res != 0)
-					break;
 			}
+			if (res != dsz)
+				break;
 		}
 	}
 	buf_safe_discard(buf);

-- 
Mark Haverkamp <ma...@os...>

Re: [Tipc-discussion] Yet another version checked in

[Jon M. <jon...@er...>]

The last thing I did before the port_lock changes was to add
a device notifier in eth_media, and a "tipc_block_bearer()"
function to handle this. I tested this with an  "ifconfig eth1 down/up" 
(I run dual links most of the time) during traffic, and this worked
fine, but when I thereafter removed the module  I got a crash
in bcast.c/blink_remove(), - a NULL pointer access. 

I corrected this (I believed) and tested it, but it seems like I 
have still introduced some problem here. 

Maybe Guo or Ling can say more about this ? Pay special
attention to the flag "blocked" in the bearer, if this gets stuck with
 with the wrong value the traffic will never restart. 

/Jon

Daniel McNeil wrote:


On Tue, 2004-05-18 at 17:19, Jon Maloy wrote:

  

I think I have succeeded in making the port/transport level lock

handling somewhat easier to understand, without changing the

basic locking policy.



    



I was testing multicast and Mark had updated 2 of the machines to 

use the latest tipc cvs and multicast sendto()s were not being

seen by a process on one of the nodes running the latest version.



I changed the tipc version on the node whose messages were not

being seen to Monday's checked in version.  (2 nodes running

monday's version and 1 running latest) the multicast sends

are correctly seen by all processes on all nodes.



Something is not quite right.  Any ideas?



Daniel



  

Re: [Tipc-discussion] Yet another version checked in

[Daniel M. <da...@os...>]

On Tue, 2004-05-18 at 17:19, Jon Maloy wrote:
> I think I have succeeded in making the port/transport level lock
> handling somewhat easier to understand, without changing the
> basic locking policy.
> 

I was testing multicast and Mark had updated 2 of the machines to 
use the latest tipc cvs and multicast sendto()s were not being
seen by a process on one of the nodes running the latest version.

I changed the tipc version on the node whose messages were not
being seen to Monday's checked in version.  (2 nodes running
monday's version and 1 running latest) the multicast sends
are correctly seen by all processes on all nodes.

Something is not quite right.  Any ideas?

Daniel

Re: [Tipc-discussion] Re: tipc panic with page alloc debug.

[Jon M. <jon...@er...>]

Hmm, this doesn't look good. The send queue is probably inconsistent,
(crs == 0) and (next_out != 0), since a valid buffer pointer hardly can
cause this crash. (buf_busy() calls skb_shared(), which does 
atomic_read() on skb->users; => no more pointer accesses.)

In older versions of TIPC we had a configurable check of link
consistency. You could re-introduce some simplified version
of it and check at each send/recv, and then dump the link
(link_print()) when it happens. I suspect a buffer overrun,
where the UB->next pointer has been overwritten by some
earlier packet sending.

Time to suspect the bundling send function again....

/Jon

Mark Haverkamp wrote:


On Tue, 2004-05-18 at 10:39, Jon Maloy wrote:

  

Hi Mark,

I haven't tried with 64 processes yet, but I will try to reproduce

and trouble-shoot this problem when I have time. Right now I am

spending some time on making the lock handling at port/socket level

more symmetric and easier to follow. It will have some

performance implications, but it will not have any major impact,

I think.



I must admit that I am not familiar with Bugzilla. Is this the base

for the bug reporting/tracking system we already have for each

project, or is it  something else ? The bug report system has only

been used sporadically, as you may have noticed, but I have no

problems with starting to use it more systematically; - I think

indeed we will have to if TIPC makes it into the kernel.



/Jon



Mark Haverkamp wrote:



    

I was running a modified tipc benchmark program that used 64 processes

instead of 32.  I also had my kernel compiled with page alloc debug

turned on (memory allocations are unmapped when free to catch bad access

as soon as possible).  It was part way through the 16K size when the

panic happened.  It was on the server side.



Any thoughts on using the sourceforge bugzilla to keep track of current

bugs?



Mark.





[root@cl019 root]# 

Unable to handle kernel paging request at virtual address f1067fe4

printing eip:

f8a8617e

*pde = 00585067

      



[ ... ]



  


After I Installed the latest tipc this morning I got another crash

similar to the last except this time the pointer is NULL.  Looking at

the disassembly, it is calling buf_busy in tipc_recv_msg.  I think at

line 1624.



[root@cl019 root]# 

Unable to handle kernel NULL pointer dereference at virtual address
00000008

 printing eip:

f8e43204

*pde = 00000000

Oops: 0000 [#1]

SMP DEBUG_PAGEALLOC

CPU:    0

EIP:    0060:[<f8e43204>]    Not tainted

EFLAGS: 00010246   (2.6.6-rc3)

EIP is at tipc_recv_msg+0x174/0x8a0 [tipc]

eax: 00000000   ebx: f650af50   ecx: 000091bc   edx: f4903f50

esi: f650af94   edi: f3f24bf8   ebp: c04fbea0   esp: c04fbe48

ds: 007b   es: 007b   ss: 0068

Process swapper (pid: 0, threadinfo=c04fa000 task=c04621c0)

Stack: f5b52bf8 00000000 f7fffe60 ee376000 0000005a 0000005a 00000246
f650af50

       0000000c 000091bc 0000920b ef0f8e18 f475cf50 f48767f8 00000001
00000000

       f743ba20 0000000b c04fbeb0 f8e6cdc0 f475cf50 c054f970 c04fbeb0
f8e61959

Call Trace:

 [<f8e61959>] recv_msg+0x39/0x50 [tipc]

 [<c0375e92>] netif_receive_skb+0x172/0x1b0

 [<c0375f54>] process_backlog+0x84/0x120

 [<c0376070>] net_rx_action+0x80/0x120

 [<c0124c38>] __do_softirq+0xb8/0xc0

 [<c0124c75>] do_softirq+0x35/0x40

 [<c0107cf5>] do_IRQ+0x175/0x230

 [<c0103040>] default_idle+0x0/0x40

 [<c0105ce0>] common_interrupt+0x18/0x20

 [<c0103040>] default_idle+0x0/0x40

 [<c0103070>] default_idle+0x30/0x40

 [<c0103106>] cpu_idle+0x46/0x50

 [<c04fc9aa>] start_kernel+0x18a/0x1d0

 [<c04fc520>] unknown_bootoption+0x0/0x130



  

Re: [Tipc-discussion] Re: tipc panic with page alloc debug.

[Mark H. <ma...@os...>]

On Tue, 2004-05-18 at 10:39, Jon Maloy wrote:
> Hi Mark,
> I haven't tried with 64 processes yet, but I will try to reproduce
> and trouble-shoot this problem when I have time. Right now I am
> spending some time on making the lock handling at port/socket level
> more symmetric and easier to follow. It will have some
> performance implications, but it will not have any major impact,
> I think.
> 
> I must admit that I am not familiar with Bugzilla. Is this the base
> for the bug reporting/tracking system we already have for each
> project, or is it  something else ? The bug report system has only
> been used sporadically, as you may have noticed, but I have no
> problems with starting to use it more systematically; - I think
> indeed we will have to if TIPC makes it into the kernel.
> 
> /Jon
> 
> Mark Haverkamp wrote:
> 
> >I was running a modified tipc benchmark program that used 64 processes
> >instead of 32.  I also had my kernel compiled with page alloc debug
> >turned on (memory allocations are unmapped when free to catch bad access
> >as soon as possible).  It was part way through the 16K size when the
> >panic happened.  It was on the server side.
> >
> >Any thoughts on using the sourceforge bugzilla to keep track of current
> >bugs?
> >
> >Mark.
> >
> >
> >[root@cl019 root]# 
> >Unable to handle kernel paging request at virtual address f1067fe4
> > printing eip:
> >f8a8617e
> >*pde = 00585067

[ ... ]

> >

After I Installed the latest tipc this morning I got another crash
similar to the last except this time the pointer is NULL.  Looking at
the disassembly, it is calling buf_busy in tipc_recv_msg.  I think at
line 1624.

[root@cl019 root]# 
Unable to handle kernel NULL pointer dereference at virtual address 00000008
 printing eip:
f8e43204
*pde = 00000000
Oops: 0000 [#1]
SMP DEBUG_PAGEALLOC
CPU:    0
EIP:    0060:[<f8e43204>]    Not tainted
EFLAGS: 00010246   (2.6.6-rc3)
EIP is at tipc_recv_msg+0x174/0x8a0 [tipc]
eax: 00000000   ebx: f650af50   ecx: 000091bc   edx: f4903f50
esi: f650af94   edi: f3f24bf8   ebp: c04fbea0   esp: c04fbe48
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c04fa000 task=c04621c0)
Stack: f5b52bf8 00000000 f7fffe60 ee376000 0000005a 0000005a 00000246 f650af50
       0000000c 000091bc 0000920b ef0f8e18 f475cf50 f48767f8 00000001 00000000
       f743ba20 0000000b c04fbeb0 f8e6cdc0 f475cf50 c054f970 c04fbeb0 f8e61959
Call Trace:
 [<f8e61959>] recv_msg+0x39/0x50 [tipc]
 [<c0375e92>] netif_receive_skb+0x172/0x1b0
 [<c0375f54>] process_backlog+0x84/0x120
 [<c0376070>] net_rx_action+0x80/0x120
 [<c0124c38>] __do_softirq+0xb8/0xc0
 [<c0124c75>] do_softirq+0x35/0x40
 [<c0107cf5>] do_IRQ+0x175/0x230
 [<c0103040>] default_idle+0x0/0x40
 [<c0105ce0>] common_interrupt+0x18/0x20
 [<c0103040>] default_idle+0x0/0x40
 [<c0103070>] default_idle+0x30/0x40
 [<c0103106>] cpu_idle+0x46/0x50
 [<c04fc9aa>] start_kernel+0x18a/0x1d0
 [<c04fc520>] unknown_bootoption+0x0/0x130

-- 
Mark Haverkamp <ma...@os...>

Re: [Tipc-discussion] [BUG]send function cannot send messages whose size are more than 66000 bytes

[Nick Y. <ni...@ho...>]

Jon,

Thank you! I will try to track the bug and report the further progress to 
you.

Best regards,

Nick

>From: Jon Maloy <jon...@er...>
>To: Nick Yin <ni...@ho...>
>CC: hu...@in..., ma...@os..., tip...@li...
>Subject: Re: [Tipc-discussion] [BUG]send function cannot send messages 
>whose size are more than 66000 bytes
>Date: Wed, 19 May 2004 11:47:46 -0400
>
>Ok,
>If you get "Invalid argument" with size > 66000 and SOCK_STREAM that
>means there is a bug. For the other types it is the correct behaviour.
>If you look into the function "send_stream()" in socket.c you will
>see how a big message is fragmented into smaller chunks of 66000 bytes
>(which in their turn are fragmented into ethernet packets further down in 
>the
>stack).
>
>If you follow the logics of send_stream() you may find out what is wrong.
>I am not at all surprised that this does not work right away.
>
>/jon
>
>
>Nick Yin wrote:
>
>>Hi, Jon and Mark
>>
>>In fact i have tested all kinds of socket type, including SOCK_STREAM, 
>>SOCK_SEQPACKET, SOCK_RDM and SOCK_DGRAM, and two connection styles ( 
>>connection-based, connectionless). The tests all failed. Whichever i using 
>>sendto or send to send big message ( > 66000 bytes), they always return -1 
>>and the errno will be 22 ( that is, "Invalid argument").
>>
>>And i also tested the big size message using TCP/IP protocol, it works 
>>well.
>>
>>Would you like to give me some suggestion to fix this bug?
>>
>>Have a nice day!
>>
>>Best regards,
>>
>>Nick Yin
>>
>>(BTW: this is another account of mine :-) )
>>
>>>From: Jon Maloy <jon...@er...>
>>>To: "Yin, Hu" <hu...@in...>
>>>CC: tipc <tip...@li...>
>>>Subject: Re: [Tipc-discussion] [BUG]send function cannot send messages 
>>>whose size are more than 66000 bytes
>>>Date: Wed, 19 May 2004 09:55:21 -0400
>>>
>>>Hi Hu,
>>>It does fragment/defragment messages, but only up to a limit, depending
>>>on the socket type you are using. If you use message oriented sockets,
>>>i.e., SOCK_SEQPACKET,SOCK_RDM or SOCK_DGRAM, it will
>>>only fragment up to MAX_MSG_SIZE, which is indeed 66000 bytes.
>>>
>>>If you use SOCK_STREAM, it will fragment up to a size of 100 Mbyte
>>>per sent "chunk". I must admit that I have still not tested this feature
>>>beyond 66k (this is on my TODO list), so you may quite well run into
>>>bugs here.  Any feedback on this is welcome.
>>>
>>>Regards /Jon
>>>
>>>Yin, Hu wrote:
>>>
>>>>Hi Jon,
>>>>
>>>>I'm a intern of Intel China Software Lab. Now I'm doing TIPC's
>>>>validation job here.
>>>>
>>>>Today I meet a problem. When I write a little program to send/receive
>>>>different sizes message between two programs there will be error( errno:
>>>>22, "Invalid argument") when the size of message is more than 66000
>>>>bytes.
>>>>
>>>>Doesn't TIPC fragment and defragment messages?
>>>>
>>>>Best regards,
>>>>
>>>>Nick Yin
>>>>
>>>>Intel China Software Lab
>>>>
>>>>The content of this email message solely contains my own personal views,
>>>>and not those of my employer.
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by: SourceForge.net Broadband
>>>>Sign-up now for SourceForge Broadband and get the fastest
>>>>6.0/768 connection for only $19.95/mo for the first 3 months!
>>>>http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
>>>>_______________________________________________
>>>>TIPC-discussion mailing list
>>>>TIP...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>>>
>>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by: SourceForge.net Broadband
>>>Sign-up now for SourceForge Broadband and get the fastest
>>>6.0/768 connection for only $19.95/mo for the first 3 months!
>>>http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
>>>_______________________________________________
>>>TIPC-discussion mailing list
>>>TIP...@li...
>>>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>
>>
>>_________________________________________________________________
>>The new MSN 8: advanced junk mail protection and 2 months FREE* 
>>http://join.msn.com/?page=features/junkmail
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: SourceForge.net Broadband
>Sign-up now for SourceForge Broadband and get the fastest
>6.0/768 connection for only $19.95/mo for the first 3 months!
>http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
>_______________________________________________
>TIPC-discussion mailing list
>TIP...@li...
>https://lists.sourceforge.net/lists/listinfo/tipc-discussion

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Tipc-discussion] [BUG]send function cannot send messageswhose size are more than 66000 bytes

[Nick Y. <ni...@ho...>]

Ok, i know, thank you!

>From: Mark Haverkamp <ma...@os...>
>To: Nick Yin <ni...@ho...>
>CC: Jon Maloy <jon...@er...>, hu...@in...,   tipc 
><tip...@li...>
>Subject: Re: [Tipc-discussion] [BUG]send function cannot send messageswhose 
>size are more than 66000 bytes
>Date: Wed, 19 May 2004 08:48:09 -0700
>
>On Wed, 2004-05-19 at 08:23, Nick Yin wrote:
> > Hi, Jon and Mark
> >
> > In fact i have tested all kinds of socket type, including SOCK_STREAM,
> > SOCK_SEQPACKET, SOCK_RDM and SOCK_DGRAM, and two connection styles (
> > connection-based, connectionless). The tests all failed. Whichever i 
>using
> > sendto or send to send big message ( > 66000 bytes), they always return 
>-1
> > and the errno will be 22 ( that is, "Invalid argument").
> >
> > And i also tested the big size message using TCP/IP protocol, it works 
>well.
> >
> > Would you like to give me some suggestion to fix this bug?
>
>I'd put some debug printk in send_stream() and see where the function is
>exiting with the error.
>
>Mark.
>
>--
>Mark Haverkamp <ma...@os...>
>

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Re: [Tipc-discussion] [BUG]send function cannot send messages whose size are more than 66000 bytes

[Mark H. <ma...@os...>]

On Wed, 2004-05-19 at 08:23, Nick Yin wrote:
> Hi, Jon and Mark
> 
> In fact i have tested all kinds of socket type, including SOCK_STREAM, 
> SOCK_SEQPACKET, SOCK_RDM and SOCK_DGRAM, and two connection styles ( 
> connection-based, connectionless). The tests all failed. Whichever i using 
> sendto or send to send big message ( > 66000 bytes), they always return -1 
> and the errno will be 22 ( that is, "Invalid argument").
> 
> And i also tested the big size message using TCP/IP protocol, it works well.
> 
> Would you like to give me some suggestion to fix this bug?

I'd put some debug printk in send_stream() and see where the function is
exiting with the error.

Mark.

-- 
Mark Haverkamp <ma...@os...>

Re: [Tipc-discussion] [BUG]send function cannot send messages whose size are more than 66000 bytes

[Jon M. <jon...@er...>]

Ok,
If you get "Invalid argument" with size > 66000 and SOCK_STREAM that
means there is a bug. For the other types it is the correct behaviour.
If you look into the function "send_stream()" in socket.c you will
see how a big message is fragmented into smaller chunks of 66000 bytes
(which in their turn are fragmented into ethernet packets further down 
in the
stack).

If you follow the logics of send_stream() you may find out what is wrong.
I am not at all surprised that this does not work right away.

/jon


Nick Yin wrote:

> Hi, Jon and Mark
>
> In fact i have tested all kinds of socket type, including SOCK_STREAM, 
> SOCK_SEQPACKET, SOCK_RDM and SOCK_DGRAM, and two connection styles ( 
> connection-based, connectionless). The tests all failed. Whichever i 
> using sendto or send to send big message ( > 66000 bytes), they always 
> return -1 and the errno will be 22 ( that is, "Invalid argument").
>
> And i also tested the big size message using TCP/IP protocol, it works 
> well.
>
> Would you like to give me some suggestion to fix this bug?
>
> Have a nice day!
>
> Best regards,
>
> Nick Yin
>
> (BTW: this is another account of mine :-) )
>
>> From: Jon Maloy <jon...@er...>
>> To: "Yin, Hu" <hu...@in...>
>> CC: tipc <tip...@li...>
>> Subject: Re: [Tipc-discussion] [BUG]send function cannot send 
>> messages whose size are more than 66000 bytes
>> Date: Wed, 19 May 2004 09:55:21 -0400
>>
>> Hi Hu,
>> It does fragment/defragment messages, but only up to a limit, depending
>> on the socket type you are using. If you use message oriented sockets,
>> i.e., SOCK_SEQPACKET,SOCK_RDM or SOCK_DGRAM, it will
>> only fragment up to MAX_MSG_SIZE, which is indeed 66000 bytes.
>>
>> If you use SOCK_STREAM, it will fragment up to a size of 100 Mbyte
>> per sent "chunk". I must admit that I have still not tested this feature
>> beyond 66k (this is on my TODO list), so you may quite well run into
>> bugs here.  Any feedback on this is welcome.
>>
>> Regards /Jon
>>
>> Yin, Hu wrote:
>>
>>> Hi Jon,
>>>
>>> I'm a intern of Intel China Software Lab. Now I'm doing TIPC's
>>> validation job here.
>>>
>>> Today I meet a problem. When I write a little program to send/receive
>>> different sizes message between two programs there will be error( 
>>> errno:
>>> 22, "Invalid argument") when the size of message is more than 66000
>>> bytes.
>>>
>>> Doesn't TIPC fragment and defragment messages?
>>>
>>> Best regards,
>>>
>>> Nick Yin
>>>
>>> Intel China Software Lab
>>>
>>> The content of this email message solely contains my own personal 
>>> views,
>>> and not those of my employer.
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: SourceForge.net Broadband
>>> Sign-up now for SourceForge Broadband and get the fastest
>>> 6.0/768 connection for only $19.95/mo for the first 3 months!
>>> http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
>>> _______________________________________________
>>> TIPC-discussion mailing list
>>> TIP...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: SourceForge.net Broadband
>> Sign-up now for SourceForge Broadband and get the fastest
>> 6.0/768 connection for only $19.95/mo for the first 3 months!
>> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
>> _______________________________________________
>> TIPC-discussion mailing list
>> TIP...@li...
>> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>
>
> _________________________________________________________________
> The new MSN 8: advanced junk mail protection and 2 months FREE* 
> http://join.msn.com/?page=features/junkmail

Re: [Tipc-discussion] [BUG]send function cannot send messages whose size are more than 66000 bytes

[Nick Y. <ni...@ho...>]

Hi, Jon and Mark

In fact i have tested all kinds of socket type, including SOCK_STREAM, 
SOCK_SEQPACKET, SOCK_RDM and SOCK_DGRAM, and two connection styles ( 
connection-based, connectionless). The tests all failed. Whichever i using 
sendto or send to send big message ( > 66000 bytes), they always return -1 
and the errno will be 22 ( that is, "Invalid argument").

And i also tested the big size message using TCP/IP protocol, it works well.

Would you like to give me some suggestion to fix this bug?

Have a nice day!

Best regards,

Nick Yin

(BTW: this is another account of mine :-) )

>From: Jon Maloy <jon...@er...>
>To: "Yin, Hu" <hu...@in...>
>CC: tipc <tip...@li...>
>Subject: Re: [Tipc-discussion] [BUG]send function cannot send messages 
>whose size are more than 66000 bytes
>Date: Wed, 19 May 2004 09:55:21 -0400
>
>Hi Hu,
>It does fragment/defragment messages, but only up to a limit, depending
>on the socket type you are using. If you use message oriented sockets,
>i.e., SOCK_SEQPACKET,SOCK_RDM or SOCK_DGRAM, it will
>only fragment up to MAX_MSG_SIZE, which is indeed 66000 bytes.
>
>If you use SOCK_STREAM, it will fragment up to a size of 100 Mbyte
>per sent "chunk". I must admit that I have still not tested this feature
>beyond 66k (this is on my TODO list), so you may quite well run into
>bugs here.  Any feedback on this is welcome.
>
>Regards /Jon
>
>Yin, Hu wrote:
>
>>Hi Jon,
>>
>>I'm a intern of Intel China Software Lab. Now I'm doing TIPC's
>>validation job here.
>>
>>Today I meet a problem. When I write a little program to send/receive
>>different sizes message between two programs there will be error( errno:
>>22, "Invalid argument") when the size of message is more than 66000
>>bytes.
>>
>>Doesn't TIPC fragment and defragment messages?
>>
>>Best regards,
>>
>>Nick Yin
>>
>>Intel China Software Lab
>>
>>The content of this email message solely contains my own personal views,
>>and not those of my employer.
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: SourceForge.net Broadband
>>Sign-up now for SourceForge Broadband and get the fastest
>>6.0/768 connection for only $19.95/mo for the first 3 months!
>>http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
>>_______________________________________________
>>TIPC-discussion mailing list
>>TIP...@li...
>>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>
>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: SourceForge.net Broadband
>Sign-up now for SourceForge Broadband and get the fastest
>6.0/768 connection for only $19.95/mo for the first 3 months!
>http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
>_______________________________________________
>TIPC-discussion mailing list
>TIP...@li...
>https://lists.sourceforge.net/lists/listinfo/tipc-discussion

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Re: [Tipc-discussion] Yet another version checked in

[Mark H. <ma...@os...>]

On Tue, 2004-05-18 at 17:19, Jon Maloy wrote:
> I think I have succeeded in making the port/transport level lock
> handling somewhat easier to understand, without changing the
> basic locking policy.
> 
> New:
> 
> 1: Callbacks to socket.c (dispatcher/wakeup dipatcher) are now
>     called with and return with the port-lock on.
> 
> 2: Symmetry: A port or subscription is now always
>     locked/unlocked in the same function.

These are a good idea.  It makes it a lot easier to follow when you can
see the scope of a lock without having to look through a bunch of called
functions to find out whether a lock was released in one of them.


> 
> 3: No dual-purpose functions to the reference manager;
>     ref_lock_acquire/ref_unlock_discard etc are now gone.
>     The port lock is still located in the corresponding reference
>     entry, though, and is accessed via easily comprehensible
>     inline functions; port_lock()/port_unlock() etc.
> 
> 4: Better comments about what the locks protect, and what
>     the lock functions do.
> 
> I will continue with a similar work on the node locks in a few days,
> but I would welcome some feedback first.

I've loaded it on to a couple of my systems and will try it out today.

Mark.

-- 
Mark Haverkamp <ma...@os...>