Re: [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE

2006-08-10 Thread Jacques GANGLOFF 

 That looks like a correct behaviour to me: the kernel module is trying
to read from pipe1 (MyPipe0, /dev/rtp0) and is blocked on it. The
user-space tool tries to do the same (is this intended BTW?). Then the
user-space program gets terminate, thus pipe1 is cleaned up. During that
cleanup all RT-readers on the pipe are woken up with -EINTR as return
code [1].


Hi Jan,

Thanks for your reply.

Indeed, I was on a wrong track: [CTRL-C] closed the application and also
the pipes, thus sending this INTR signal to the kernel module.

BTW, is there a limit to the size of a message one can send in a pipe.
Could this limit be around 65535 ?

I'm porting a RTAI application to xenomai and I am still hunting a bug on
a pipe. Writing on the user side more than 65530 bytes on a pipe yields a
Cannot allocate memory perror message.

Thanks a lot for your hints,
Jacques

 ___

   Prof. Jacques GANGLOFF

   Strasbourg I University
   LSIIT Laboratory, EAVR team
   Bd S. Brant
   BP 10413, 67412 ILLKIRCH cedex, FRANCE
   Tel : +33 (0)3 90 24 44 68
   Fax : +33 (0)3 90 24 44 80
   http://eavr.u-strasbg.fr






___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE

2006-08-10 Thread Dmitry Adamushko 

Hello,

take a look at the 4-th parameter of rt_pipe_create() :

@param poolsize Specifies the size of a dedicated buffer pool for the
* pipe. Passing 0 means that all message allocations for this pipe are
* performed on the system heap.
The system heap is also used for other allocations and not only to
serve a given heap. It's default size is 128 Kb (configurable through
the config though).

Passing non-zero parameter causes a private heap of the given size to be created for this heap.

Note, it's a size in bytes, not a flag (in your example you use 1 for the second heap). 

This value is rounded up to a page size.

rt_pipe_create()
{
...
if (poolsize  2 * PAGE_SIZE)

poolsize = 2 * PAGE_SIZE;

 poolsize = xnheap_rounded_size(poolsize, PAGE_SIZE);


-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

RE : [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE

2006-08-09 Thread Jacques GANGLOFF 
Hello,

I tested this with xenomai version V2.1.2 and V2.2 : same behavior.

Regards,
Jacques


 ___

   Prof. Jacques GANGLOFF

   Strasbourg I University
   LSIIT Laboratory, EAVR team
   Bd S. Brant
   BP 10413, 67412 ILLKIRCH cedex, FRANCE
   Tel : +33 (0)3 90 24 44 68
   Fax : +33 (0)3 90 24 44 80
   http://eavr.u-strasbg.fr



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE

2006-08-09 Thread Jan Kiszka 
Jacques GANGLOFF wrote:
 Hi,
 
 I did this little test :
 
 Below I have attached two sources, one on the kernel side and one on the
 user side.
 I do here a very simple fifo handshaking test. I insert the kernel module
 then I run the user program. When I do the test with the THE BUG IS HERE
 line commented, I got :
 
 [EMAIL PROTECTED]:~/test/pipe# ./user
 user : j'ai envoyé A
 user :j'ai bien reçu E
 [EMAIL PROTECTED]:~/test/pipe# dmesg
 hello world
 kernel : j'ai bien reçu A
 kernel : ret = 1
 kernel :j'ai envoyé E
 
 Now, when I uncomment the line :
 [EMAIL PROTECTED]:~/test/pipe# ./user
 user : j'ai envoyé A
 [CRTL-C] because the user program is blocking ...
 [EMAIL PROTECTED]:~/test/pipe# dmesg
 hello world
 kernel : j'ai bien reçu A
 kernel : ret = -4
 kernel :j'ai envoyé E
 

That looks like a correct behaviour to me: the kernel module is trying
to read from pipe1 (MyPipe0, /dev/rtp0) and is blocked on it. The
user-space tool tries to do the same (is this intended BTW?). Then the
user-space program gets terminate, thus pipe1 is cleaned up. During that
cleanup all RT-readers on the pipe are woken up with -EINTR as return
code [1].

 
 Now, ret=-4 is the code for -EINTR. According to the doc :
 -EINTR is returned if rt_task_unblock() has been called for the waiting
 task before any data was available.
 
 I cannot see where rt_task_unblock() could be called. What is wrong ?
 

Ok, the documentation is insufficient here. We should actually add the
second reason for EINTR as sketched above.

Jan


[1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#L607



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core