From: Nick Y. <ni...@ho...> - 2004-05-21 04:54:02
|
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 |