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
Re: [Xenomai-core] SMI update
Ulrich Schwab wrote: > I saw some bad latency behaviour on a new system, it is a > P4 with ICH7 chipset. It showed more than 300 us max. latency without any > load. > This chipset was not detected as SMI generating and SMI disable was not done. > > Finally I figured out where to add this DEVICE_ID > to the SMI detection in smi.c > It is done in the attached patch. > > Now, the max. latency values on this new system are below 10 us. > Although, not tested very long. ...and not under load. ;) Thanks for the patch, we just need some additional define of PCI_DEVICE_ID_INTEL_ICH7_0 for kernel 2.4 compatibility. And if you additionally provide a ChangeLog fragment, your patch would be perfect! (I tend to forget the last part often too... :) ) Jan signature.asc Description: OpenPGP digital signature ___ 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
[Xenomai-core] SMI update
I saw some bad latency behaviour on a new system, it is a P4 with ICH7 chipset. It showed more than 300 us max. latency without any load. This chipset was not detected as SMI generating and SMI disable was not done. Finally I figured out where to add this DEVICE_ID to the SMI detection in smi.c It is done in the attached patch. Now, the max. latency values on this new system are below 10 us. Although, not tested very long. Regards, Ulrich Schwab -- inmess GmbH Frankfurter Str. 74 D - 64521 Gross-Gerau Phone: +49 6152 97790 Fax : +49 6152 977920 mail : [EMAIL PROTECTED] web: www.inmess.de diff -urp xenomai-2.2.0/ksrc/arch/i386/smi.c xenomai-2.2-patched/ksrc/arch/i386/smi.c --- xenomai-2.2.0/ksrc/arch/i386/smi.c 2006-07-03 08:44:33.0 +0200 +++ xenomai-2.2-patched/ksrc/arch/i386/smi.c 2006-08-09 18:20:57.0 +0200 @@ -45,6 +45,7 @@ static struct pci_device_id rthal_smi_pc { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_0) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_2) }, +{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_0) }, { 0, }, }; ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?
> So could anyone test this patch and let me know if it works?>> Note : I haven't compiled it even as I don't have a proper environment. But > the changes are pretty simple so it should be ok.I just did run the test program supplied by Vincent after applying Your patch(against 2.2.0)It did work ! That's good. Thanks for your assistance. So synch. message passing interface (IOW, rt_task_send/receive/reply) is mgmglmgmm... slightly broken at the moment for all versions. The ones who need it may use this patch so far. I'll think a bit more on it in the mean time but I tend to think that "Fixed Ownership" (expressed by XNSYNCH_FOWNER) should really be a property of the synch. object indeed (as in the current patch). > Only one small typo was in the patch, it is fixed in the attached patch > version. Ok, now I need to run diff -u old-patch new-patch to find out this typo :) -- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?
On Wednesday 09 August 2006 13:42, Dmitry Adamushko wrote: > So could anyone test this patch and let me know if it works? > > Note : I haven't compiled it even as I don't have a proper environment. But > the changes are pretty simple so it should be ok. I just did run the test program supplied by Vincent after applying Your patch (against 2.2.0) It did work ! Only one small typo was in the patch, it is fixed in the attached patch version. > > There was actually yet another problem mmm... who cares to delete a sender > from the msendq? > > Now should be ok or maybe I'm completely wrong and see the things which do > not exist at all :) > > p.s. I cc'ed "xenomai-core" as it may involve further discussions and it's > the right place indeed. -- inmess GmbH Frankfurter Str. 74 D - 64521 Gross-Gerau Phone: +49 6152 97790 Fax : +49 6152 977920 mail : [EMAIL PROTECTED] web: www.inmess.de diff -urp xenomai-a/include/nucleus/synch.h xenomai-b/include/nucleus/synch.h --- xenomai-a/include/nucleus/synch.h 2006-07-20 11:09:01.0 +0200 +++ xenomai-b/include/nucleus/synch.h 2006-08-09 12:53:37.044217000 +0200 @@ -28,6 +28,7 @@ #define XNSYNCH_NOPIP 0x0 #define XNSYNCH_PIP 0x2 #define XNSYNCH_DREORD 0x4 +#define XNSYNCH_FOWNER 0x20 /* Fixed owner */ #if defined(__KERNEL__) || defined(__XENO_SIM__) diff -urp xenomai-a/ksrc/nucleus/synch.c xenomai-b/ksrc/nucleus/synch.c --- xenomai-a/ksrc/nucleus/synch.c 2006-06-15 14:15:25.0 +0200 +++ xenomai-b/ksrc/nucleus/synch.c 2006-08-09 13:28:55.199081000 +0200 @@ -37,6 +37,14 @@ #include #include +/* temporarily here */ +static inline void xnsynch_set_owner_internal(xnsynch_t *synch, xnthread_t *thread) +{ + if (!testbits(synch->status, XNSYNCH_FOWNER)) + synch->owner = thread; +} + + /*! * \fn void xnsynch_init(xnsynch_t *synch, xnflags_t flags); * \brief Initialize a synchronization object. @@ -181,7 +189,7 @@ void xnsynch_sleep_on(xnsynch_t *synch, if (testbits(synch->status, XNSYNCH_PENDING)) { /* Ownership is still pending, steal the resource. */ - synch->owner = thread; + xnsynch_set_owner_internal(synch, thread); __clrbits(thread->status, XNRMID | XNTIMEO | XNBREAK); goto grab_ownership; @@ -209,7 +217,7 @@ void xnsynch_sleep_on(xnsynch_t *synch, xnpod_suspend_thread(thread, XNPEND, timeout, synch); - if (unlikely(synch->owner != thread)) { + if (!testbits(synch->status, XNSYNCH_FOWNER) && unlikely(synch->owner != thread)) { /* Somebody stole us the ownership while we were ready to run, waiting for the CPU: we need to wait again for the resource. */ @@ -362,12 +370,12 @@ xnthread_t *xnsynch_wakeup_one_sleeper(x if (holder) { thread = link2thread(holder, plink); thread->wchan = NULL; - synch->owner = thread; + xnsynch_set_owner_internal(synch, thread); __setbits(synch->status, XNSYNCH_PENDING); xnltt_log_event(xeno_ev_wakeup1, thread->name, synch); xnpod_resume_thread(thread, XNPEND); } else { - synch->owner = NULL; + xnsynch_set_owner_internal(synch, thread); __clrbits(synch->status, XNSYNCH_PENDING); } @@ -435,7 +443,7 @@ xnpholder_t *xnsynch_wakeup_this_sleeper nholder = poppq(&synch->pendq, holder); thread = link2thread(holder, plink); thread->wchan = NULL; - synch->owner = thread; + xnsynch_set_owner_internal(synch, thread); __setbits(synch->status, XNSYNCH_PENDING); xnltt_log_event(xeno_ev_wakeupx, thread->name, synch); xnpod_resume_thread(thread, XNPEND); @@ -523,7 +531,7 @@ int xnsynch_flush(xnsynch_t *synch, xnfl status = XNSYNCH_RESCHED; } - synch->owner = NULL; + xnsynch_set_owner_internal(synch, NULL); __clrbits(synch->status, XNSYNCH_PENDING); xnlock_put_irqrestore(&nklock, s); diff -urp xenomai-a/ksrc/skins/native/task.c xenomai-b/ksrc/skins/native/task.c --- xenomai-a/ksrc/skins/native/task.c 2006-07-30 10:50:49.0 +0200 +++ xenomai-b/ksrc/skins/native/task.c 2006-08-09 13:32:21.91777 +0200 @@ -262,7 +262,7 @@ int rt_task_create(RT_TASK *task, #ifdef CONFIG_XENO_OPT_NATIVE_MPS xnsynch_init(&task->mrecv, XNSYNCH_FIFO); - xnsynch_init(&task->msendq, XNSYNCH_PRIO | XNSYNCH_PIP); + xnsynch_init(&task->msendq, XNSYNCH_PRIO | XNSYNCH_PIP | XNSYNCH_FOWNER); xnsynch_set_owner(&task->msendq, &task->thread_base); task->flowgen = 0; #endif /* CONFIG_XENO_OPT_NATIVE_MPS */ @@ -2057,10 +2057,7 @@ int rt_task_reply(int flowid, RT_TASK_MC identifier from other senders wrt to a given receiver. */ if (receiver->wait_args.mps.mcb_s.flowid == flowid) { - /* Note that the following will cause the receiver to be - unblocked without transferring the ownership of the - msendq object, since we want the sender to keep it. */ - xnpod_resume_thread(&receiver->thread_base, XNPEND); + xnsynch_wakeup_this_sleeper(&sender->msendq, holder); break;
[Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?
So could anyone test this patch and let me know if it works? Note : I haven't compiled it even as I don't have a proper environment. But the changes are pretty simple so it should be ok. There was actually yet another problem mmm... who cares to delete a sender from the msendq? Now should be ok or maybe I'm completely wrong and see the things which do not exist at all :) p.s. I cc'ed "xenomai-core" as it may involve further discussions and it's the right place indeed. -- Best regards,Dmitry Adamushko diff -urp xenomai-a/include/nucleus/synch.h xenomai-b/include/nucleus/synch.h --- xenomai-a/include/nucleus/synch.h 2006-07-20 11:09:01.0 +0200 +++ xenomai-b/include/nucleus/synch.h 2006-08-09 12:53:37.044217000 +0200 @@ -28,6 +28,7 @@ #define XNSYNCH_NOPIP 0x0 #define XNSYNCH_PIP 0x2 #define XNSYNCH_DREORD 0x4 +#define XNSYNCH_FOWNER 0x20 /* Fixed owner */ #if defined(__KERNEL__) || defined(__XENO_SIM__) diff -urp xenomai-a/ksrc/nucleus/synch.c xenomai-b/ksrc/nucleus/synch.c --- xenomai-a/ksrc/nucleus/synch.c 2006-06-15 14:15:25.0 +0200 +++ xenomai-b/ksrc/nucleus/synch.c 2006-08-09 13:28:55.199081000 +0200 @@ -37,6 +37,14 @@ #include #include +/* temporarily here */ +static inline void xnsynch_set_owner_internal(xnsynch_t *synch, xnthread_t *thread) +{ + if (!testbits(synch->status, XNSYNCH_FOWNER)) + synch->owner = thread; +} + + /*! * \fn void xnsynch_init(xnsynch_t *synch, xnflags_t flags); * \brief Initialize a synchronization object. @@ -181,7 +189,7 @@ void xnsynch_sleep_on(xnsynch_t *synch, if (testbits(synch->status, XNSYNCH_PENDING)) { /* Ownership is still pending, steal the resource. */ - synch->owner = thread; + xnsynch_set_owner_internal(synch, thread); __clrbits(thread->status, XNRMID | XNTIMEO | XNBREAK); goto grab_ownership; @@ -209,7 +217,7 @@ void xnsynch_sleep_on(xnsynch_t *synch, xnpod_suspend_thread(thread, XNPEND, timeout, synch); - if (unlikely(synch->owner != thread)) { + if (!testbits(synch->status, XNSYNCH_OWNER) && unlikely(synch->owner != thread)) { /* Somebody stole us the ownership while we were ready to run, waiting for the CPU: we need to wait again for the resource. */ @@ -362,12 +370,12 @@ xnthread_t *xnsynch_wakeup_one_sleeper(x if (holder) { thread = link2thread(holder, plink); thread->wchan = NULL; - synch->owner = thread; + xnsynch_set_owner_internal(synch, thread); __setbits(synch->status, XNSYNCH_PENDING); xnltt_log_event(xeno_ev_wakeup1, thread->name, synch); xnpod_resume_thread(thread, XNPEND); } else { - synch->owner = NULL; + xnsynch_set_owner_internal(synch, thread); __clrbits(synch->status, XNSYNCH_PENDING); } @@ -435,7 +443,7 @@ xnpholder_t *xnsynch_wakeup_this_sleeper nholder = poppq(&synch->pendq, holder); thread = link2thread(holder, plink); thread->wchan = NULL; - synch->owner = thread; + xnsynch_set_owner_internal(synch, thread); __setbits(synch->status, XNSYNCH_PENDING); xnltt_log_event(xeno_ev_wakeupx, thread->name, synch); xnpod_resume_thread(thread, XNPEND); @@ -523,7 +531,7 @@ int xnsynch_flush(xnsynch_t *synch, xnfl status = XNSYNCH_RESCHED; } - synch->owner = NULL; + xnsynch_set_owner_internal(synch, NULL); __clrbits(synch->status, XNSYNCH_PENDING); xnlock_put_irqrestore(&nklock, s); diff -urp xenomai-a/ksrc/skins/native/task.c xenomai-b/ksrc/skins/native/task.c --- xenomai-a/ksrc/skins/native/task.c 2006-07-30 10:50:49.0 +0200 +++ xenomai-b/ksrc/skins/native/task.c 2006-08-09 13:32:21.91777 +0200 @@ -262,7 +262,7 @@ int rt_task_create(RT_TASK *task, #ifdef CONFIG_XENO_OPT_NATIVE_MPS xnsynch_init(&task->mrecv, XNSYNCH_FIFO); - xnsynch_init(&task->msendq, XNSYNCH_PRIO | XNSYNCH_PIP); + xnsynch_init(&task->msendq, XNSYNCH_PRIO | XNSYNCH_PIP | XNSYNCH_FOWNER); xnsynch_set_owner(&task->msendq, &task->thread_base); task->flowgen = 0; #endif /* CONFIG_XENO_OPT_NATIVE_MPS */ @@ -2057,10 +2057,7 @@ int rt_task_reply(int flowid, RT_TASK_MC identifier from other senders wrt to a given receiver. */ if (receiver->wait_args.mps.mcb_s.flowid == flowid) { - /* Note that the following will cause the receiver to be - unblocked without transferring the ownership of the - msendq object, since we want the sender to keep it. */ - xnpod_resume_thread(&receiver->thread_base, XNPEND); + xnsynch_wakeup_this_sleeper(&sender->msendq, holder); break; } } ___ 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 #include #include #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 #include #include #include #include #include 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