Re: [Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE
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
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
[Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE
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
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 ?
Thanks for your help,
Jacques
==
Kernel module :
==
#include native/task.h
#include native/pipe.h
#include rtdm/rtdm_driver.h
#define TASK_PRIO 99
#define TASK_MODE T_FPU|T_CPU(0)
#define TASK_STKSZ 4096
RT_PIPE pipe1,pipe2;
RT_TASK task_desc;
void task_body (void *cookie)
{
char buf,mesg;
int err;
mesg = 'E';
/*lecture dans le pipe (TM_INFINITE : bloque la tâche s'il y a rien dans
* le pipe)*/
err = rt_pipe_read(pipe1,buf,sizeof(char),TM_INFINITE);
rtdm_printk(kernel : j'ai bien reçu %c \n,buf);
/* THE BUG IS HERE */
err = rt_pipe_read(pipe1,buf,sizeof(char),TM_INFINITE);
/* THE BUG IS HERE */
rtdm_printk(kernel : ret = %d\n, err );
/*écriture dans le pipe*/
err = rt_pipe_write(pipe2,mesg,sizeof(char),P_NORMAL);
rtdm_printk(kernel :j'ai envoyé %c \n,mesg);
}
int init_module(void)
{
int err=0;
printk(hello world\n);
/*Création d'un pipe pour lecture*/
err = rt_pipe_create(pipe1,MyPipe0,0,sizeof(char));
if(err)
{
rtdm_printk(pipe MyPipe0 creation failure \n);
}
/*Création d'un pipe pour écriture*/
err = rt_pipe_create(pipe2,MyPipe1,1,sizeof(char));
if(err)
{
rtdm_printk(pipe MyPipe1 creation failure \n);
}
/*Création de la tâche*/
err =
rt_task_create(task_desc,MyTaskName,TASK_STKSZ,TASK_PRIO,TASK_MODE);
if (!err)
{
/*lancement de la tâche*/
rt_task_start(task_desc,task_body,NULL);
}
return 0;
}
void cleanup_module(void)
{
rt_task_delete(task_desc);
rt_pipe_delete(pipe1);
rt_pipe_delete(pipe2);
}
===
User program :
===
#include native/task.h
#include native/pipe.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include fcntl.h
int main()
{
int pipe1,pipe2;
char m2,m1='A';
m2 = 0;
/*Ouverture du device côté user pour écriture */
pipe1 = open(/dev/rtp0,O_RDWR);
/*Ouverture du device côté user pour lecture*/
pipe2 = open(/dev/rtp1,O_RDONLY);
/*écriture des données*/
write(pipe1,m1,sizeof(char));
printf(user : j'ai envoyé %c \n,m1);
/* lecture des données */
read(pipe2,m2,sizeof(char));
printf(user :j'ai bien reçu %c \n,m2);
close(pipe1);
close(pipe2);
return 0;
}
___
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
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
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
