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

RE: [Tipc-discussion] RE: TIPCv2 test spec!

[Yin, H. <hu...@in...>]

Jon,

=20

Thanks for your reply. I'm here waiting for your latest TIPC version,
hehe : - )

=20

Have a nice day!

=20

Nick

-----Original Message-----
From: Jon Maloy [mailto:jon...@er...]=20
Sent: Saturday, June 05, 2004 2:38 AM
To: Mark Haverkamp
Cc: Yin, Hu; tipc
Subject: Re: [Tipc-discussion] RE: TIPCv2 test spec!

=20

No, you must have a "management connection" to the node
to be able to do this kind of changes. The idea is that a user land
process on one of the nodes ("zone master") takes command from=20
the beginning and establishes one such connection to all the other=20
nodes, and then holds on this connection as long as it is running.

Each TIPC module only allows one such connection, and will
reject all other setup requests, so as long as we make sure that
the zone master is started on a trusted processor and holds on to
its connection we should be safe.

As an extra precaution I have in the version I am working on now
made this whole remote configurability configurable, so that if shut=20
off TIPC only accepts commands from the local node. This is one of=20
the commands, (along with change of node address and a few more)=20
that go via ioctl() instead of via the management port.=20

What I am working on now is such a client CLM process, but I have had to
concentrate on the basic stuff, such as setting node address and
enabling/
disabling bearers on the local node, so there is no zone master yet.
This=20
will have to wait until later; I will check in what I have as soon as I
have=20
merged with the latest changes and tested with running traffic.

/Jon

Mark Haverkamp wrote:



On Thu, 2004-06-03 at 05:59, Jon Maloy wrote:
 =20

	Good.
	When/if you find the problem just send me the patch(es).
	In a couple of days I will check in  a version where we
	rely entirely on the management interface (=3Dno more
	insmod parameters), so this must work.
	=20
	/Jon
	=20
	   =20

=20
I don't see any protection against anyone doing link configuration
commands via the management interface.  Could just anyone reconfigure
links, disable bearers, etc.?
=20
=20
 =20

=20

[Tipc-discussion] Difference between Name subscription and Network subscription

[Yin, H. <hu...@in...>]

Hi, All

I cannot distinguish Name subscription and Network subscription. Who can
tell me=20
the difference between Name subscription and Network subscription? Thank
you in advance!

Here is the description abstracted from TIPC's testspec:

------------------------------------------------------------------------
--------------
Name subscription Test Program
------------------------------
1) Open several subscriptons for <0,0,0xffffffff> from one socket.
   socket. This will in practice work like a network subscription,
   and one should receive an event per subscription each time a=20
   processor goes down or comes back. Disable/enable the bearers
   on a processor to verify.
2) Call the syncronous NAME_AVAILABILITY for one name that does
   exist and for one that does not.


Network Subscription Test Program
---------------------------------
Open a subscripton for <0> from a socket. Disable/enable a processor.
------------------------------------------------------------------------
-------------

Thanks,

Nick

Re: [Tipc-discussion] RE: TIPCv2 test spec!

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

No, you must have a "management connection" to the node
to be able to do this kind of changes. The idea is that a user land
process on one of the nodes ("zone master") takes command from 
the beginning and establishes one such connection to all the other 
nodes, and then holds on this connection as long as it is running.

Each TIPC module only allows one such connection, and will
reject all other setup requests, so as long as we make sure that
the zone master is started on a trusted processor and holds on to
its connection we should be safe.

As an extra precaution I have in the version I am working on now
made this whole remote configurability configurable, so that if shut 
off TIPC only accepts commands from the local node. This is one of 
the commands, (along with change of node address and a few more) 
that go via ioctl() instead of via the management port. 

What I am working on now is such a client CLM process, but I have had to
concentrate on the basic stuff, such as setting node address and
enabling/
disabling bearers on the local node, so there is no zone master yet.
This 
will have to wait until later; I will check in what I have as soon as I
have 
merged with the latest changes and tested with running traffic.

/Jon

Mark Haverkamp wrote:


On Thu, 2004-06-03 at 05:59, Jon Maloy wrote:

  

Good.

When/if you find the problem just send me the patch(es).

In a couple of days I will check in  a version where we

rely entirely on the management interface (=no more

insmod parameters), so this must work.



/Jon



    



I don't see any protection against anyone doing link configuration

commands via the management interface.  Could just anyone reconfigure

links, disable bearers, etc.?





  

Re: [Tipc-discussion] RE: TIPCv2 test spec!

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

On Thu, 2004-06-03 at 05:59, Jon Maloy wrote:
> Good.
> When/if you find the problem just send me the patch(es).
> In a couple of days I will check in  a version where we
> rely entirely on the management interface (=no more
> insmod parameters), so this must work.
> 
> /Jon
> 

I don't see any protection against anyone doing link configuration
commands via the management interface.  Could just anyone reconfigure
links, disable bearers, etc.?


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

Re: [Tipc-discussion] Sending to a wide name sequence is slow

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

No, it should not be like that. I hope Ling will look into it ?
/jon

hek...@ya... wrote:

>Hello, 
>
>In one experiemnt, the server listens to name instance: 0x10001a21
>and the client sends to name sequence: 0x10000000 - 0x13ffffff.
>
>It seems it takes forever for the client's sendto() to return.
>Is this expected behavior ?
>
>Thanks!
>
>Kevin
>  
>

[Tipc-discussion] Sending to a wide name sequence is slow

[<hek...@ya...>]

Hello, 

In one experiemnt, the server listens to name instance: 0x10001a21
and the client sends to name sequence: 0x10000000 - 0x13ffffff.

It seems it takes forever for the client's sendto() to return.
Is this expected behavior ?

Thanks!

Kevin

RE: [Tipc-discussion] RE: TIPCv2 test spec!

[Yin, H. <hu...@in...>]

Jon,

Understand. Thank you!

Best Regards,

Nick Yin
-----Original Message-----
From: Jon Maloy [mailto:jon...@er...]=20
Sent: Thursday, June 03, 2004 8:59 PM
To: Yin, Hu
Cc: tip...@li...
Subject: Re: [Tipc-discussion] RE: TIPCv2 test spec!

Good.
When/if you find the problem just send me the patch(es).
In a couple of days I will check in  a version where we
rely entirely on the management interface (=3Dno more
insmod parameters), so this must work.

/Jon

Yin, Hu wrote:

>Jon,
>
>During the test of TIPC, I found some functions of manager.c don't
work,
>for example, TIPC_CREATE_LINK doesn't create a new link,
>TIPC_SET_LINK_TOLERANCE doesn't reset the link's parameters, and etc.
>
>In addition, when I try to send TIPC_BLOCK_LINK event to manager, my
>machine hang and cannot response any keyboard and mouse event, so I
have
>to reboot my machine, hehe:-)
>
>So far I just found these problems!
>
>Have a nice day!
>
>Best Regards,
>
>Nick Yin
> =20
>

Re: [Tipc-discussion] RE: TIPCv2 test spec!

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

Good.
When/if you find the problem just send me the patch(es).
In a couple of days I will check in  a version where we
rely entirely on the management interface (=no more
insmod parameters), so this must work.

/Jon

Yin, Hu wrote:

>Jon,
>
>During the test of TIPC, I found some functions of manager.c don't work,
>for example, TIPC_CREATE_LINK doesn't create a new link,
>TIPC_SET_LINK_TOLERANCE doesn't reset the link's parameters, and etc.
>
>In addition, when I try to send TIPC_BLOCK_LINK event to manager, my
>machine hang and cannot response any keyboard and mouse event, so I have
>to reboot my machine, hehe:-)
>
>So far I just found these problems!
>
>Have a nice day!
>
>Best Regards,
>
>Nick Yin
>  
>

RE: [Tipc-discussion] RE: TIPCv2 test spec!

[Yin, H. <hu...@in...>]

Jon,

During the test of TIPC, I found some functions of manager.c don't work,
for example, TIPC_CREATE_LINK doesn't create a new link,
TIPC_SET_LINK_TOLERANCE doesn't reset the link's parameters, and etc.

In addition, when I try to send TIPC_BLOCK_LINK event to manager, my
machine hang and cannot response any keyboard and mouse event, so I have
to reboot my machine, hehe:-)

So far I just found these problems!

Have a nice day!

Best Regards,

Nick Yin

[Tipc-discussion] RE: TIPCv2 test spec!

[Yin, H. <hu...@in...>]

Jon,

Thank you very much! But it seems that the task is very difficult for
me, anyway I will try my best to do it. Hope I can continue to get help
from you all.Thanks!

Best Regards,

Nick Yin

-----Original Message-----
From: Jon Maloy [mailto:jon...@er...]=20
Sent: Wednesday, June 02, 2004 9:41 PM
To: Yin, Hu
Cc: tip...@li...
Subject: Re: TIPCv2 test spec!

Hi,
NAME_AVAILABLE is still there, but is now called
TIPC_BLOCK_SUBSCRIBE. What really has been removed
is the "preferred/load shared" options when you publish a port
name sequence. Instead, this selection is now done by the caller, by
indicating a "lookup domain" (it is described in the IETF draft).
The lookup domain decides whether the "closest first" (~ preferred) or
"round robin" (~load shared) algorithms should be used, but also
how far out in the network the algorithm should be looking.

There exists no design spec for the current version of TIPC, so
you will have to do with the IETF draft and the code for now :-)

Regards /jon

Yin, Hu wrote:

>Hi,
>
>As you know there is a test spec for TIPCv1, but now TIPC has gone to
>v2. Some of the items in test spec for TIPCv1 are not suitable or don't
>work for TIPCv2. For example, the following is some of the content:
>-----------------------------------------------------------------------
-
>----
>-----------------------------------------------------------------------
-
>----
>Name Table Test Program
>-----------------------
>
>1) Publish 1000 port names, some of them from the same port.
>2) Call NAME_AVAILABLE to verify that the names are really
>   published.
>2) Withdraw these port names in a different order than they=20
>   were published.
>2) Call NAME_AVAILABLE to verify that the names are really
>   withdrawn.
>3) Publish different types:
>     Load shared. Many from same processor, and from
>                 different processors
>     Preferred load shared.Verify that you are refused a=20
>                  second publication.
>     Illegal suite: lower > upper
>     Overlapping suites: Verifiy that these are rejected.
>     Publications with different visibility: Zone,Subnet,Processor
>              Call NAME_AVAILABLE again to verify publication scope.
>-----------------------------------------------------------------------
-
>----
>-----------------------------------------------------------------------
-
>----
>
>but you know there is not a NAME_AVAILABLE event in TIPCv2 source code
>at all. So I think we'd better update and improve the old test spec
from
>v1 to v2. Is there a new test spec for TIPCv2 or not? If not, I'd like
>to work out a test spec for TIPCv2 according to v1, but I need more
>information about TIPCv2, such as the design spec and etc. So can you
>provide me some good materials and help me to work out that together,
>thank you very much in advance!
>
>Best Regards
>
>Nick Yin
>
>Jun 2, 2004
> =20
>

Re: [Tipc-discussion] name_table.c printk

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

On Wed, 2004-06-02 at 14:47, Jon Maloy wrote:
> Not only there. They should be replaced everywhere with
> the appropriate level dbg(),warn(),info() etc.  I see there
> is quite a few of them left in i bcast code.

bcast.c was updated last week by xfling to remove pritnk calls.

Mark.


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

Re: [Tipc-discussion] name_table.c printk

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

Not only there. They should be replaced everywhere with
the appropriate level dbg(),warn(),info() etc.  I see there
is quite a few of them left in i bcast code.

/jon

Mark Haverkamp wrote:

>I'd like to propose changing the printk calls in name_table.c to dbg
>calls.  This eliminates lots of chatter on my console.
>
>Mark.
>
>cvs diff -u name_table.c
>Index: name_table.c
>===================================================================
>RCS file: /cvsroot/tipc/source/unstable/net/tipc/name_table.c,v
>retrieving revision 1.18
>diff -u -r1.18 name_table.c
>--- name_table.c	10 May 2004 21:07:57 -0000	1.18
>+++ name_table.c	2 Jun 2004 21:34:32 -0000
>@@ -750,7 +750,7 @@
> 			destnode = publ->node;
> 			destport = publ->ref;
> 			if (destport) {
>-				printk("mc table\n");
>+				dbg("mc table\n");
> 				if (in_list_node(mc_head, destnode)) {
> 					if (false ==
> 					    mc_identity_create(mc_head,
>@@ -828,7 +828,7 @@
> 			destnode = publ->node;
> 			destport = publ->ref;
> 			if (destport && (destnode == tipc_own_addr)) {
>-				printk("self table\n");
>+				dbg("self table\n");
> 				if (in_list(mc_head, destport, destnode)) {
> 					if (false ==
> 					    mc_identity_create(mc_head,
>@@ -845,7 +845,7 @@
> 		/*      
> 		   if (destport && (destnode == tipc_own_addr))
> 		   {
>-		   printk("self trans\n");
>+		   dbg("self trans\n");
> 		   if ( false == mc_indenity_create(mc_head,destport,destnode)) {
> 		   spin_unlock_bh(&seq->lock);
> 		   goto not_found;      
>
>  
>

[Tipc-discussion] name_table.c printk

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

I'd like to propose changing the printk calls in name_table.c to dbg
calls.  This eliminates lots of chatter on my console.

Mark.

cvs diff -u name_table.c
Index: name_table.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/name_table.c,v
retrieving revision 1.18
diff -u -r1.18 name_table.c
--- name_table.c	10 May 2004 21:07:57 -0000	1.18
+++ name_table.c	2 Jun 2004 21:34:32 -0000
@@ -750,7 +750,7 @@
 			destnode = publ->node;
 			destport = publ->ref;
 			if (destport) {
-				printk("mc table\n");
+				dbg("mc table\n");
 				if (in_list_node(mc_head, destnode)) {
 					if (false ==
 					    mc_identity_create(mc_head,
@@ -828,7 +828,7 @@
 			destnode = publ->node;
 			destport = publ->ref;
 			if (destport && (destnode == tipc_own_addr)) {
-				printk("self table\n");
+				dbg("self table\n");
 				if (in_list(mc_head, destport, destnode)) {
 					if (false ==
 					    mc_identity_create(mc_head,
@@ -845,7 +845,7 @@
 		/*      
 		   if (destport && (destnode == tipc_own_addr))
 		   {
-		   printk("self trans\n");
+		   dbg("self trans\n");
 		   if ( false == mc_indenity_create(mc_head,destport,destnode)) {
 		   spin_unlock_bh(&seq->lock);
 		   goto not_found;      

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

[Tipc-discussion] RE: sendbcast/recvbcast patch

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

On Sun, 2004-05-30 at 18:06, Ling, Xiaofeng wrote:
> Ok, That's great fix=EF=BC=81 The code is more stable now.
>=20

I checked these changes in today.

Mark.

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

[Tipc-discussion] Re: TIPCv2 test spec!

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

Hi,
NAME_AVAILABLE is still there, but is now called
TIPC_BLOCK_SUBSCRIBE. What really has been removed
is the "preferred/load shared" options when you publish a port
name sequence. Instead, this selection is now done by the caller, by
indicating a "lookup domain" (it is described in the IETF draft).
The lookup domain decides whether the "closest first" (~ preferred) or
"round robin" (~load shared) algorithms should be used, but also
how far out in the network the algorithm should be looking.

There exists no design spec for the current version of TIPC, so
you will have to do with the IETF draft and the code for now :-)

Regards /jon

Yin, Hu wrote:

>Hi,
>
>As you know there is a test spec for TIPCv1, but now TIPC has gone to
>v2. Some of the items in test spec for TIPCv1 are not suitable or don't
>work for TIPCv2. For example, the following is some of the content:
>------------------------------------------------------------------------
>----
>------------------------------------------------------------------------
>----
>Name Table Test Program
>-----------------------
>
>1) Publish 1000 port names, some of them from the same port.
>2) Call NAME_AVAILABLE to verify that the names are really
>   published.
>2) Withdraw these port names in a different order than they 
>   were published.
>2) Call NAME_AVAILABLE to verify that the names are really
>   withdrawn.
>3) Publish different types:
>     Load shared. Many from same processor, and from
>                 different processors
>     Preferred load shared.Verify that you are refused a 
>                  second publication.
>     Illegal suite: lower > upper
>     Overlapping suites: Verifiy that these are rejected.
>     Publications with different visibility: Zone,Subnet,Processor
>              Call NAME_AVAILABLE again to verify publication scope.
>------------------------------------------------------------------------
>----
>------------------------------------------------------------------------
>----
>
>but you know there is not a NAME_AVAILABLE event in TIPCv2 source code
>at all. So I think we'd better update and improve the old test spec from
>v1 to v2. Is there a new test spec for TIPCv2 or not? If not, I'd like
>to work out a test spec for TIPCv2 according to v1, but I need more
>information about TIPCv2, such as the design spec and etc. So can you
>provide me some good materials and help me to work out that together,
>thank you very much in advance!
>
>Best Regards
>
>Nick Yin
>
>Jun 2, 2004
>  
>

[Tipc-discussion] TIPCv2 test spec!

[Yin, H. <hu...@in...>]

Hi,

As you know there is a test spec for TIPCv1, but now TIPC has gone to
v2. Some of the items in test spec for TIPCv1 are not suitable or don't
work for TIPCv2. For example, the following is some of the content:
------------------------------------------------------------------------
----
------------------------------------------------------------------------
----
Name Table Test Program
-----------------------

1) Publish 1000 port names, some of them from the same port.
2) Call NAME_AVAILABLE to verify that the names are really
   published.
2) Withdraw these port names in a different order than they=20
   were published.
2) Call NAME_AVAILABLE to verify that the names are really
   withdrawn.
3) Publish different types:
     Load shared. Many from same processor, and from
                 different processors
     Preferred load shared.Verify that you are refused a=20
                  second publication.
     Illegal suite: lower > upper
     Overlapping suites: Verifiy that these are rejected.
     Publications with different visibility: Zone,Subnet,Processor
              Call NAME_AVAILABLE again to verify publication scope.
------------------------------------------------------------------------
----
------------------------------------------------------------------------
----

but you know there is not a NAME_AVAILABLE event in TIPCv2 source code
at all. So I think we'd better update and improve the old test spec from
v1 to v2. Is there a new test spec for TIPCv2 or not? If not, I'd like
to work out a test spec for TIPCv2 according to v1, but I need more
information about TIPCv2, such as the design spec and etc. So can you
provide me some good materials and help me to work out that together,
thank you very much in advance!

Best Regards

Nick Yin

Jun 2, 2004

[Tipc-discussion] RE: sendbcast/recvbcast patch

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

Ok, That's great fix=A3=A1 The code is more stable now.

>-----Original Message-----
>From: Mark Haverkamp [mailto:ma...@os...]=20
>Sent: 2004=C4=EA5=D4=C227=C8=D5 1:05
>To: Ling, Xiaofeng; Jon Maloy; tipc
>Subject: sendbcast/recvbcast patch
>
>I went through sendbcast and recvbcast and fixed the return codes.=20
>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=20
>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=20
>TIPC_FAILURE is
>-22 and can not be confused with a size.
>
>Mark.
>
>
>cvs diff -u recvbcast.c sendbcast.c
>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.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 @@
> }
>=20
> /**
>-  *  Add the buf to the ownership node  deferred queue,update=20
>defer_inqueue size and gap
>+  *  Add the buf to the ownership node  deferred queue,update=20
>defer_inqueue=20
>+  *  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
>   */
>=20
> static int
>@@ -241,9 +244,12 @@
> }
>=20
> /**
>-  *  Recaulte the gap, accord to the defer queue packet's=20
>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=20
>seqno, reorgnize=20
>+  *  them and send them to port, update the gap, defer_queue_size,=20
>+  *  last_in_bcast.
>+  *
>   *  Input:  this:  link
>+  *
>   *  Return: void =20
>   */
> static void
>@@ -276,7 +282,8 @@
> /**
>   * process the bcast_nextsend in TIPC header.=20
>   * input: this: link
>-  *		buf: recv buf
>+  *	    buf: recv buf
>+  *
>   * return:void
>   */
> void
>@@ -307,10 +314,12 @@
> }
>=20
> /**
>-  * recieve the bcast data,case seqno equal to expect=20
>number,recv them, if greater than
>-  * expect seqno, add to defer queue.
>+  * recieve the bcast data,case seqno equal to expect=20
>number,recv them,=20
>+  * if greater than expect seqno, add to defer queue.
>+  *
>   * input: this: link
>-  *		buf: recv buf
>+  *	    buf: recv buf
>+  *
>   * return:void=20
>   */
> void
>@@ -374,9 +383,12 @@
> }
>=20
> /**
>-  * recieved the retransmit packet, which has been wraped,=20
>extract the buf and send to upper layer
>+  * recieved the retransmit packet, which has been wraped,=20
>extract the=20
>+  * buf and send to upper layer
>+  *
>   * input: this: link
>-  *		buf: recv buf
>+  *	    buf: recv buf
>+  *
>   * return:void=20
>   */
>=20
>@@ -399,7 +411,8 @@
> /**
>   * recieved the bcast state packet, handle retransmit.
>   * input: this: link
>-  *		buf: recv buf
>+  * 	    buf: recv buf
>+  *
>   * return:void=20
>   */
> void
>@@ -434,8 +447,10 @@
> /**
>   * deliver the buf to multicast member
>   * input: mc_head: mc_idenity list head
>-  *		buf: recv buf
>-  * return:void=20
>+  *	       buf: recv buf
>+  *
>+  * return:	message data size:	success
>+  * 		            other:	failure
>   */
>=20
> int
>@@ -444,8 +459,8 @@
>=20
> 	struct list_head *pos;
> 	struct mc_identity *mid;
>-	int res =3D TIPC_OK;
>-	int sz =3D msg_data_sz(buf_msg(buf));
>+	int res =3D msg_data_sz(buf_msg(buf));
>+	int sz;
>=20
> 	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 =3D port_recv_msg(copymsg);
>+				sz =3D port_recv_msg(copymsg);
> 				if (res !=3D sz)
> 					break;
> 			}
>@@ -469,8 +484,10 @@
>=20
> /**
>   * 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=20
>   */
>=20
>@@ -482,9 +499,11 @@
> }
>=20
> /**
>-  * check bcast out queue, select the minmum ack seqno and=20
>deleted all the packets which
>-  * seqno is less than the minmum seqno
>+  * check bcast out queue, select the minmum ack seqno and=20
>deleted all=20
>+  * the packets which seqno is less than the minmum seqno
>+  *
>   * input: void
>+  *
>   * return:void=20
>   */
>=20
>@@ -518,7 +537,8 @@
>   * lower level recv bcast proto message handle,=20
>differentiate their types and=20
>   * call corresponding function
>   * input: this:link
>-  *		buf: the recieved buffer
>+  *	    buf: the recieved buffer
>+  *
>   * return:void=20
>   */
>=20
>@@ -550,16 +570,19 @@
> }
>=20
> /**
>-  * port recieved function, get the mc idenity list and=20
>deliever the buf to the mc member =20
>+  * port recieved function, get the mc idenity list and=20
>deliever the buf=20
>+  * to the mc member.
>+  *
>   * input: buf: the recieved buffer
>-  * return:void=20
>+  *
>+  * return:	message data size:	success
>+  * 			    other:	failure
>   */
>-
> int
> bcast_port_recv(struct sk_buff *buf)
> {
> 	struct list_head mc_head;
>-	int res =3D true;
>+	int res;
> 	struct tipc_msg *msg =3D buf_msg(buf);
>=20
> 	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 =3D nameseq_deliver(buf, &mc_head);
> 	free_mclist(&mc_head);
>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.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 =3D nametbl_mc_translate(&mc_head, seq->type,=20
>seq->lower, seq->upper);
> 	if (res =3D=3D false)
>-		return TIPC_ERR_NO_NAME;
>+		return TIPC_FAILURE;
> 	tipc_ownidentity(ref, &orig);
> 	hdr =3D &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
>   */
>=20
> int
>@@ -409,6 +410,9 @@
>  * blink_send_buf() is the 'full path' for messages, called from=20
>  * inside TIPC when the 'fast path' in=20
>tipc_send_buf/tipc_send_sections=20
>  * has failed, and from link_send()
>+ *
>+ * 	return message data size:	success
>+ * 	       		   other:	failure
>  */
>=20
> static int
>@@ -420,6 +424,8 @@
> 	uint imp =3D msg_tot_importance(msg);
> 	uint queue_limit =3D this->queue_limit[imp];
> 	uint max_packet =3D link_max_pkt(this);
>+	uint dsz =3D msg_data_sz(msg);
>+
> 	msg_set_prevnode(msg, tipc_own_addr);
>=20
> 	if (unlikely(queue_size >=3D queue_limit)) {
>@@ -434,12 +440,11 @@
> 			warn("Resetting %s, send queue full",=20
>this->name);
> 			link_reset(this);
> 		}
>-		return TIPC_OK;
>+		return dsz;
> 	}
>=20
> 	if (size > max_packet) {
>-		link_send_long_buf(this, buf);
>-		return TIPC_OK;
>+		return link_send_long_buf(this, buf);
> 	}
>=20
> 	if (queue_size > this->stats.max_queue_sz)
>@@ -454,22 +459,22 @@
> 			bearer_schedule(this->bearer, this);
> 			this->next_out =3D buf;
> 		}
>-		return TIPC_OK;
>+		return dsz;
> 	}
>=20
> 	if (!this->next_out)
> 		this->next_out =3D buf;
> 	blink_add_to_outqueue(this, buf);
> 	bearer_resolve_congestion(this->bearer, this);
>-	return TIPC_OK;
>+	return dsz;
> }
>=20
> /**
>   * send out the broadcast buf using common link,add the buf=20
>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
>   */
>=20
> int
>@@ -478,7 +483,7 @@
>=20
> 	struct tipc_msg *msg =3D buf_msg(buf);
> 	if (likely(this)) {
>-		int res =3D TIPC_OK;
>+		int res =3D msg_data_sz(msg);
> 		if (likely(!link_congested(this))) {
> 			if (likely(msg_size(msg) <=3D=20
>link_max_pkt(this))) {
> 				if (likely(
>@@ -501,7 +506,6 @@
> 					=09
>bearer_schedule(this->bearer,
> 								this);
> 						this->next_out =3D buf;
>-						res =3D TIPC_OK;
> 						goto exit;
> 					}
> 				}
>@@ -514,7 +518,7 @@
> 	if (msg_destnode(msg) =3D=3D tipc_own_addr)
> 		return port_recv_msg(buf);
> 	tipc_reject_msg(buf, TIPC_ERR_NO_NODE);
>-	return TIPC_OK;
>+	return TIPC_FAILURE;
> }
>=20
> /**
>@@ -679,10 +683,11 @@
>=20
> /**
>   * 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,=20
>uint lastseq)
>
>--=20
>Mark Haverkamp <ma...@os...>
>
>

[Tipc-discussion] Re: issues building tipc against 2.6.5

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

See below.
/jon

Chris Friesen wrote:

> Jon Maloy wrote:
>
>> The 1.2-line of TIPC os only maintained for the 2.4-kernel. If you want
>> to run
>> TIPC on 2.6, you should use the 1.3-line, which is now approaching 
>> the same
>> stability (we are not quite there yet). Note that the API and insmod
>> parameters
>> have changed in the 1.3-line, but you will like the changes, I think.
>
>
> Okay, I think I figured it out.  It was not obvious to me that I 
> needed to build in source/unstable.
>
>
> A couple comments:
>
> 1) I think the "clean" line in the Makefile should read
>
> rm -f net/tipc/*.ko
>
> and not
>
> rm -f /net/tipc/*.ko 

Yes, of course.

>
>
>
> 2) The duplicated Makefiles in source/unstable and 
> source/unstable/net/tipc is kind of grungy. 

These files don't have the same purpose. The one under unstable/net/tipc 
is for use when
TIPC is integrated into its right place in the kernel, and can not be 
used at all
for standalone build.  This file must be kept as "standard" as possible 
to please the
kernel guys.

The other one is an optional support for standalone build of the module, and
must be kept outside the tipc directory because of its interaction with 
the Linux module
build support. (This basically expects to find a file with the name 
"Makefile" under
"SUB_DIRS", and since we already have a file with that name under 
net/tipc I had
to use a different SUB_DIRS.)

You will find more issues when you start looking at the code, but it is 
improving
by the day :-)

Regards /Jon

>
>
> Chris

[Tipc-discussion] Re: issues building tipc against 2.6.5

[Chris F. <cfr...@no...>]

Jon Maloy wrote:
> The 1.2-line of TIPC os only maintained for the 2.4-kernel. If you want
> to run
> TIPC on 2.6, you should use the 1.3-line, which is now approaching the same
> stability (we are not quite there yet). Note that the API and insmod
> parameters
> have changed in the 1.3-line, but you will like the changes, I think.

Okay, I think I figured it out.  It was not obvious to me that I needed 
to build in source/unstable.


A couple comments:

1) I think the "clean" line in the Makefile should read

rm -f net/tipc/*.ko

and not

rm -f /net/tipc/*.ko


2) The duplicated Makefiles in source/unstable and 
source/unstable/net/tipc is kind of grungy.

Chris

[Tipc-discussion] Re: issues building tipc against 2.6.5

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

The 1.2-line of TIPC os only maintained for the 2.4-kernel. If you want 
to run
TIPC on 2.6, you should use the 1.3-line, which is now approaching the same
stability (we are not quite there yet). Note that the API and insmod 
parameters
have changed in the 1.3-line, but you will like the changes, I think.

/Jon

Chris Friesen wrote:

>
> I downloaded the latest CVS version and tried building against a 2.6.5 
> x86 tree.  Got a bunch of errors (see below) wrt include files.
>
> The issue seems to be that irq_vectors.h is actually located in 
> asm/mach-default, which isn't in the search path.
>
> Has anyone managed to build this?
>
> Chris
>
>
>
>
> [cfriesen@pcard0ks cvs]$ make TOPDIR=/usr/local/misc/kernel/linux-2.6.5
> cd ./TIPC_SCC && make 
> KINCLUDE=/usr/local/misc/kernel/linux-2.6.5/include all
> make[1]: Entering directory `/usr/local/misc/tipc/cvs/TIPC_SCC'
> cc -M  -DTIPC_LINUX_2_6 -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB 
> -I../EnvAdaptation_SWI/incl -I../TIPC_SWI/incl 
> -I../TipcAdaptation_SWI/incl 
> -I/usr/local/misc/kernel/linux-2.6.5/include -I./src ./src/Address.c 
> ./src/Bearer.c ./src/Debug.c ./src/Link.c ./src/LinkSubscription.c 
> ./src/Manager.c ./src/Memory.c ./src/Message.c ./src/NameDistributor.c 
> ./src/NameSubscription.c ./src/NameTable.c ./src/Network.c 
> ./src/NetworkSubscription.c ./src/Port.c ./src/Processor.c 
> ./src/Reference.c ./src/Subnetwork.c ./src/tipc_port.c ./src/Zone.c | 
> sed -e 's|^.*\.o:|./obj.linuxm/\0|g' > .deps
> In file included from 
> /usr/local/misc/kernel/linux-2.6.5/include/linux/irq.h:20,
>                  from 
> /usr/local/misc/kernel/linux-2.6.5/include/asm/hardirq.h:6,
>                  from 
> /usr/local/misc/kernel/linux-2.6.5/include/linux/interrupt.h:11,
>                  from 
> ../EnvAdaptation_SWI/incl/tipc_linuxm_adaptation.h:69,
>                  from 
> ../EnvAdaptation_SWI/incl/tipc_target_adaptation.h:68,
>                  from ../TipcAdaptation_SWI/incl/tipc_adaptation.h:805,
>                  from src/Debug.h:61,
>                  from ./src/Address.c:57:
> /usr/local/misc/kernel/linux-2.6.5/include/asm/irq.h:16:25: 
> irq_vectors.h: No such file or directory
> In file included from 
> /usr/local/misc/kernel/linux-2.6.5/include/linux/irq.h:20,
>                  from 
> /usr/local/misc/kernel/linux-2.6.5/include/asm/hardirq.h:6,
>                  from 
> /usr/local/misc/kernel/linux-2.6.5/include/linux/interrupt.h:11,
>                  from 
> ../EnvAdaptation_SWI/incl/tipc_linuxm_adaptation.h:69,
>                  from 
> ../EnvAdaptation_SWI/incl/tipc_target_adaptation.h:68,
>                  from ../TipcAdaptation_SWI/incl/tipc_adaptation.h:805,
>                  from src/Debug.h:61,
>                  from ./src/Bearer.c:60:
> /usr/local/misc/kernel/linux-2.6.5/include/asm/irq.h:16:25: 
> irq_vectors.h: No such file or directory

[Tipc-discussion] issues building tipc against 2.6.5

[Chris F. <cfr...@no...>]

I downloaded the latest CVS version and tried building against a 2.6.5 
x86 tree.  Got a bunch of errors (see below) wrt include files.

The issue seems to be that irq_vectors.h is actually located in 
asm/mach-default, which isn't in the search path.

Has anyone managed to build this?

Chris




[cfriesen@pcard0ks cvs]$ make TOPDIR=/usr/local/misc/kernel/linux-2.6.5
cd ./TIPC_SCC && make 
KINCLUDE=/usr/local/misc/kernel/linux-2.6.5/include all
make[1]: Entering directory `/usr/local/misc/tipc/cvs/TIPC_SCC'
cc -M  -DTIPC_LINUX_2_6 -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB 
-I../EnvAdaptation_SWI/incl -I../TIPC_SWI/incl 
-I../TipcAdaptation_SWI/incl 
-I/usr/local/misc/kernel/linux-2.6.5/include -I./src ./src/Address.c 
./src/Bearer.c ./src/Debug.c ./src/Link.c ./src/LinkSubscription.c 
./src/Manager.c ./src/Memory.c ./src/Message.c ./src/NameDistributor.c 
./src/NameSubscription.c ./src/NameTable.c ./src/Network.c 
./src/NetworkSubscription.c ./src/Port.c ./src/Processor.c 
./src/Reference.c ./src/Subnetwork.c ./src/tipc_port.c ./src/Zone.c | 
sed -e 's|^.*\.o:|./obj.linuxm/\0|g' > .deps
In file included from 
/usr/local/misc/kernel/linux-2.6.5/include/linux/irq.h:20,
                  from 
/usr/local/misc/kernel/linux-2.6.5/include/asm/hardirq.h:6,
                  from 
/usr/local/misc/kernel/linux-2.6.5/include/linux/interrupt.h:11,
                  from 
../EnvAdaptation_SWI/incl/tipc_linuxm_adaptation.h:69,
                  from 
../EnvAdaptation_SWI/incl/tipc_target_adaptation.h:68,
                  from ../TipcAdaptation_SWI/incl/tipc_adaptation.h:805,
                  from src/Debug.h:61,
                  from ./src/Address.c:57:
/usr/local/misc/kernel/linux-2.6.5/include/asm/irq.h:16:25: 
irq_vectors.h: No such file or directory
In file included from 
/usr/local/misc/kernel/linux-2.6.5/include/linux/irq.h:20,
                  from 
/usr/local/misc/kernel/linux-2.6.5/include/asm/hardirq.h:6,
                  from 
/usr/local/misc/kernel/linux-2.6.5/include/linux/interrupt.h:11,
                  from 
../EnvAdaptation_SWI/incl/tipc_linuxm_adaptation.h:69,
                  from 
../EnvAdaptation_SWI/incl/tipc_target_adaptation.h:68,
                  from ../TipcAdaptation_SWI/incl/tipc_adaptation.h:805,
                  from src/Debug.h:61,
                  from ./src/Bearer.c:60:
/usr/local/misc/kernel/linux-2.6.5/include/asm/irq.h:16:25: 
irq_vectors.h: No such file or directory

[Tipc-discussion] Re: status of UDP

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

Ok, I guess the only right thing to do is to remove it then.
I will do it next time I check in code.

/jon

Mark Haverkamp wrote:


On Wed, 2004-05-26 at 12:36, Jon Maloy wrote:

  

Hi Mark,

I have not tested TIPC/UDP it on 2.6 at all; last time I did it was

with 2.4 on Vmware, not on SMP hardware. There it worked fine,

but evidently something has changed in the kernel since then.



I have a feeling that we are fighting losing battle here, trying

to use UDP in a way not anticipated in the Linux implementation.

I also got the feedback from IETF a few months ago that UDP was

very undesired as a carrier of TIPC, because it can be used over

the Internet in an uncontrollable way, without the inherent flow control

they want to se in all internet protocols. (Basically, I think they

would like to kill UDP as a protocol altogether, if they could.)



If you somhow can find an easy workaround for the problem you

see, it is ok to do it, otherwise I don't think we should spend much
time

on it. We should rather remove it completely for now, and at some later

moment concentrate our effort to carry TIPC over TCP or SCTP.



    



I don't think that there is an easy workaround.  I looked at the udp

code last year with the original tipc and 2.5 and saw the same

problems.  I tried to use a kernel thread to process the UDP messages so

it would be in a process context but never got it to work right.



Mark.







  

What I have in mind is that we introduce a generic media

adaptation that only has the task of conveying sent/received packets

to/from a TIPC deamon in user space. It could be this daemon's task

to set up connections and transport the packets from node to node,

ensure encryption etc.

Performance would of course suffer, but for Internet protocols execution

time in the stack is not the dominating factor anyway.

For transporting packages to/from such a deamon we can use ioctl,

Netlink, or, why not, TIPC itself.



But these are future visions, I think.



Regards /Jon

    



  

[Tipc-discussion] Re: status of UDP

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

On Wed, 2004-05-26 at 12:36, Jon Maloy wrote:
> Hi Mark,
> I have not tested TIPC/UDP it on 2.6 at all; last time I did it was
> with 2.4 on Vmware, not on SMP hardware. There it worked fine,
> but evidently something has changed in the kernel since then.
> 
> I have a feeling that we are fighting losing battle here, trying
> to use UDP in a way not anticipated in the Linux implementation.
> I also got the feedback from IETF a few months ago that UDP was
> very undesired as a carrier of TIPC, because it can be used over
> the Internet in an uncontrollable way, without the inherent flow control
> they want to se in all internet protocols. (Basically, I think they
> would like to kill UDP as a protocol altogether, if they could.)
> 
> If you somhow can find an easy workaround for the problem you
> see, it is ok to do it, otherwise I don't think we should spend much time
> on it. We should rather remove it completely for now, and at some later
> moment concentrate our effort to carry TIPC over TCP or SCTP.
> 

I don't think that there is an easy workaround.  I looked at the udp
code last year with the original tipc and 2.5 and saw the same
problems.  I tried to use a kernel thread to process the UDP messages so
it would be in a process context but never got it to work right.

Mark.



> What I have in mind is that we introduce a generic media
> adaptation that only has the task of conveying sent/received packets
> to/from a TIPC deamon in user space. It could be this daemon's task
> to set up connections and transport the packets from node to node,
> ensure encryption etc.
> Performance would of course suffer, but for Internet protocols execution
> time in the stack is not the dominating factor anyway.
> For transporting packages to/from such a deamon we can use ioctl,
> Netlink, or, why not, TIPC itself.
> 
> But these are future visions, I think.
> 
> Regards /Jon

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

[Tipc-discussion] Re: status of UDP

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

Hi Mark,
I have not tested TIPC/UDP it on 2.6 at all; last time I did it was
with 2.4 on Vmware, not on SMP hardware. There it worked fine,
but evidently something has changed in the kernel since then.

I have a feeling that we are fighting losing battle here, trying
to use UDP in a way not anticipated in the Linux implementation.
I also got the feedback from IETF a few months ago that UDP was
very undesired as a carrier of TIPC, because it can be used over
the Internet in an uncontrollable way, without the inherent flow control
they want to se in all internet protocols. (Basically, I think they
would like to kill UDP as a protocol altogether, if they could.)

If you somhow can find an easy workaround for the problem you
see, it is ok to do it, otherwise I don't think we should spend much time
on it. We should rather remove it completely for now, and at some later
moment concentrate our effort to carry TIPC over TCP or SCTP.

What I have in mind is that we introduce a generic media
adaptation that only has the task of conveying sent/received packets
to/from a TIPC deamon in user space. It could be this daemon's task
to set up connections and transport the packets from node to node,
ensure encryption etc.
Performance would of course suffer, but for Internet protocols execution
time in the stack is not the dominating factor anyway.
For transporting packages to/from such a deamon we can use ioctl,
Netlink, or, why not, TIPC itself.

But these are future visions, I think.

Regards /Jon


Mark Haverkamp wrote:

>Jon,
>
>What is the status of TIPC UDP?  Has it been tested very much?  I tried
>loading tipc with UDP today and got lots of debug stack traces.
>
>For instance I loaded tipc with:
>
>insmod ./tipc.ko udp0=1 node=17 netid=1000
>
>And started seeing these:
>
>TIPC:  Compiled May 26 2004 07:29:42
>TIPC:  Own node address <1.1.17>, network identity 1000
>Debug: sleeping function called from invalid context at mm/slab.c:1967
>in_atomic():1, irqs_disabled():0
>Call Trace:
> [<c011cce9>] __might_sleep+0x99/0xb0
> [<c014951f>] kmem_cache_alloc+0x21f/0x230
> [<c036c70e>] sock_alloc_inode+0x1e/0x80
> [<c017f9ac>] alloc_inode+0x1c/0x140
> [<c018055d>] new_inode+0x1d/0xd0
> [<c037e742>] rtnl_lock+0x22/0x40
> [<c036ca36>] sock_alloc+0x16/0x60
> [<c036d846>] sock_create+0x86/0x230
> [<f8e5e9ec>] enable_bearer+0xac/0x470 [tipc]
> [<f8e464f7>] tipc_enable_bearer+0x227/0x4b0 [tipc]
> [<f8e5ee88>] udp_media_start+0xc8/0xd0 [tipc]
> [<f8e6b099>] tipc_init+0x99/0xa7 [tipc]
> [<c013a7b9>] sys_init_module+0x179/0x2f0
> [<c0105373>] syscall_call+0x7/0xb
>                                   
>TIPC:  TIPC/UDP: Multicast listener socket on 225.0.1.232:55555
>TIPC:  TIPC/UDP: Unicast listener socket on port 55555
>TIPC:  Bearer instance <udp:udp0> enabled, broadcast domain <1.0.0>
>[root@cl017 root]# Debug: sleeping function called from invalid context at net/core/sock.c:1150
>in_atomic():1, irqs_disabled():0
>Call Trace:
> [<c011cce9>] __might_sleep+0x99/0xb0
> [<c0370632>] lock_sock+0x22/0xc0
> [<c0388d78>] ip_route_output_flow+0x18/0x30
> [<c03b01c4>] udp_sendmsg+0x264/0x800
> [<c0390360>] ip_finish_output2+0x0/0x1e0
> [<c03b950b>] inet_sendmsg+0x4b/0x60
> [<c036cbde>] sock_sendmsg+0x8e/0xb0
> [<c0119584>] recalc_task_prio+0xb4/0x1f0
> [<c01338cb>] kernel_text_address+0x3b/0x50
> [<c01193f8>] kernel_map_pages+0x28/0x64
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
> [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
> [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
> [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
> [<c011abc1>] scheduler_tick+0x111/0x690
> [<c0124f33>] tasklet_action+0x73/0xc0
> [<c0124c38>] __do_softirq+0xb8/0xc0
> [<c0124c75>] do_softirq+0x35/0x40
> [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
> [<c0103040>] default_idle+0x0/0x40
> [<c0105d62>] apic_timer_interrupt+0x1a/0x20
> [<c0103040>] default_idle+0x0/0x40
> [<c0103070>] default_idle+0x30/0x40
> [<c0103106>] cpu_idle+0x46/0x50
> [<c0120561>] printk+0x1c1/0x270
>                                 
>Debug: sleeping function called from invalid context at net/core/sock.c:1150
>in_atomic():1, irqs_disabled():0
>Call Trace:
> [<c011cce9>] __might_sleep+0x99/0xb0
> [<c0370632>] lock_sock+0x22/0xc0
> [<c0388d78>] ip_route_output_flow+0x18/0x30
> [<c03b01c4>] udp_sendmsg+0x264/0x800
> [<c0370c57>] __kfree_skb+0x77/0xf0
> [<c03b950b>] inet_sendmsg+0x4b/0x60
> [<c036cbde>] sock_sendmsg+0x8e/0xb0
> [<c0119584>] recalc_task_prio+0xb4/0x1f0
> [<c0119c1a>] wake_up_state+0x1a/0x20
> [<c012ac22>] signal_wake_up+0x32/0x50
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5a190>] k_signal+0x60/0x170 [tipc]
> [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
> [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
> [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
> [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
> [<c011abc1>] scheduler_tick+0x111/0x690
> [<c0124f33>] tasklet_action+0x73/0xc0
> [<c0124c38>] __do_softirq+0xb8/0xc0
> [<c0124c75>] do_softirq+0x35/0x40
> [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
> [<c0103040>] default_idle+0x0/0x40
> [<c0105d62>] apic_timer_interrupt+0x1a/0x20
> [<c0103040>] default_idle+0x0/0x40
> [<c0103070>] default_idle+0x30/0x40
> [<c0103106>] cpu_idle+0x46/0x50
> [<c0120561>] printk+0x1c1/0x270
>                                 
>rmmod tipc
>TIPC:  Deregistered
>
>  
>

[Tipc-discussion] status of UDP

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

Jon,

What is the status of TIPC UDP?  Has it been tested very much?  I tried
loading tipc with UDP today and got lots of debug stack traces.

For instance I loaded tipc with:

insmod ./tipc.ko udp0=1 node=17 netid=1000

And started seeing these:

TIPC:  Compiled May 26 2004 07:29:42
TIPC:  Own node address <1.1.17>, network identity 1000
Debug: sleeping function called from invalid context at mm/slab.c:1967
in_atomic():1, irqs_disabled():0
Call Trace:
 [<c011cce9>] __might_sleep+0x99/0xb0
 [<c014951f>] kmem_cache_alloc+0x21f/0x230
 [<c036c70e>] sock_alloc_inode+0x1e/0x80
 [<c017f9ac>] alloc_inode+0x1c/0x140
 [<c018055d>] new_inode+0x1d/0xd0
 [<c037e742>] rtnl_lock+0x22/0x40
 [<c036ca36>] sock_alloc+0x16/0x60
 [<c036d846>] sock_create+0x86/0x230
 [<f8e5e9ec>] enable_bearer+0xac/0x470 [tipc]
 [<f8e464f7>] tipc_enable_bearer+0x227/0x4b0 [tipc]
 [<f8e5ee88>] udp_media_start+0xc8/0xd0 [tipc]
 [<f8e6b099>] tipc_init+0x99/0xa7 [tipc]
 [<c013a7b9>] sys_init_module+0x179/0x2f0
 [<c0105373>] syscall_call+0x7/0xb
                                   
TIPC:  TIPC/UDP: Multicast listener socket on 225.0.1.232:55555
TIPC:  TIPC/UDP: Unicast listener socket on port 55555
TIPC:  Bearer instance <udp:udp0> enabled, broadcast domain <1.0.0>
[root@cl017 root]# Debug: sleeping function called from invalid context at net/core/sock.c:1150
in_atomic():1, irqs_disabled():0
Call Trace:
 [<c011cce9>] __might_sleep+0x99/0xb0
 [<c0370632>] lock_sock+0x22/0xc0
 [<c0388d78>] ip_route_output_flow+0x18/0x30
 [<c03b01c4>] udp_sendmsg+0x264/0x800
 [<c0390360>] ip_finish_output2+0x0/0x1e0
 [<c03b950b>] inet_sendmsg+0x4b/0x60
 [<c036cbde>] sock_sendmsg+0x8e/0xb0
 [<c0119584>] recalc_task_prio+0xb4/0x1f0
 [<c01338cb>] kernel_text_address+0x3b/0x50
 [<c01193f8>] kernel_map_pages+0x28/0x64
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
 [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
 [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
 [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
 [<c011abc1>] scheduler_tick+0x111/0x690
 [<c0124f33>] tasklet_action+0x73/0xc0
 [<c0124c38>] __do_softirq+0xb8/0xc0
 [<c0124c75>] do_softirq+0x35/0x40
 [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
 [<c0103040>] default_idle+0x0/0x40
 [<c0105d62>] apic_timer_interrupt+0x1a/0x20
 [<c0103040>] default_idle+0x0/0x40
 [<c0103070>] default_idle+0x30/0x40
 [<c0103106>] cpu_idle+0x46/0x50
 [<c0120561>] printk+0x1c1/0x270
                                 
Debug: sleeping function called from invalid context at net/core/sock.c:1150
in_atomic():1, irqs_disabled():0
Call Trace:
 [<c011cce9>] __might_sleep+0x99/0xb0
 [<c0370632>] lock_sock+0x22/0xc0
 [<c0388d78>] ip_route_output_flow+0x18/0x30
 [<c03b01c4>] udp_sendmsg+0x264/0x800
 [<c0370c57>] __kfree_skb+0x77/0xf0
 [<c03b950b>] inet_sendmsg+0x4b/0x60
 [<c036cbde>] sock_sendmsg+0x8e/0xb0
 [<c0119584>] recalc_task_prio+0xb4/0x1f0
 [<c0119c1a>] wake_up_state+0x1a/0x20
 [<c012ac22>] signal_wake_up+0x32/0x50
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5a190>] k_signal+0x60/0x170 [tipc]
 [<f8e5e734>] send_msg+0x94/0xa0 [tipc]
 [<f8e398f3>] cfg_send_req+0x1e3/0x230 [tipc]
 [<f8e5a34c>] timeout_receiver+0xac/0x110 [tipc]
 [<f8e5a11f>] receive_signal+0x14f/0x160 [tipc]
 [<c011abc1>] scheduler_tick+0x111/0x690
 [<c0124f33>] tasklet_action+0x73/0xc0
 [<c0124c38>] __do_softirq+0xb8/0xc0
 [<c0124c75>] do_softirq+0x35/0x40
 [<c011526d>] smp_apic_timer_interrupt+0xdd/0x150
 [<c0103040>] default_idle+0x0/0x40
 [<c0105d62>] apic_timer_interrupt+0x1a/0x20
 [<c0103040>] default_idle+0x0/0x40
 [<c0103070>] default_idle+0x30/0x40
 [<c0103106>] cpu_idle+0x46/0x50
 [<c0120561>] printk+0x1c1/0x270
                                 
rmmod tipc
TIPC:  Deregistered

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