Menu
▾
▴
tipc-discussion
|
From: Guo, M. <mi...@in...> - 2004-05-21 00:51:45
|
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);
|
|
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
|
|
From: Jon M. <jon...@er...> - 2004-05-21 22:57:10
|
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
|
|
From: Nick Y. <ni...@ho...> - 2004-05-22 05:48:41
|
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
|
|
From: Ling, X. <xia...@in...> - 2004-05-24 01:00:59
|
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
>
|
|
From: Jon M. <jon...@er...> - 2004-05-21 22:53:34
|
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)
;
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X