date:20060809

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

Re: [Xenomai-core] SMI update

2006-08-09 Thread Jan Kiszka

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

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

[Xenomai-core] SMI update

2006-08-09 Thread Ulrich Schwab


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?

2006-08-09 Thread Dmitry Adamushko

> 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?

2006-08-09 Thread Ulrich Schwab

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?

2006-08-09 Thread Dmitry Adamushko


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

2006-08-09 Thread Jacques GANGLOFF

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

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

Re: [Xenomai-core] SMI update

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

[Xenomai-core] SMI update

Re: [Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?

Re: [Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?

[Xenomai-core] Re: [Xenomai-help] -110 error on rt_task_send... bug?

[Xenomai-core] -EINTR using rt_pipe_read with TM_INFINITE

8 matches

Site Navigation

Mail list logo

Footer information