[Xenomai-help] rt_pipe and rt_queue problems

[Xenomai-help] rt_pipe and rt_queue problems

[Petr Cervenka]

I have Xenomai snapshot (18.5.2006,  2.1.1 ~ 2.1.2) and userspace application.
I need to exchange lot of data between two tasks (producer -> consumer) with some buffer in the middle.
I used rt_pipe/linux device scheme, but I realised that the preformance is very low. (At least some performance monitor showed it)
So I tried to use rt_queue. But when I tried to read from queue with timeout (or TM_INFINITE), I got an EPERM error.
That means: "service should block, but was called from a context, which cannot sleep.". But I want to sleep (and wait for new data).
Where is the problem? Do you have any advice?
Petr Cervenka

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

Petr Cervenka wrote:
> I have Xenomai snapshot (18.5.2006,  2.1.1 ~ 2.1.2) and userspace 
> application. I need to exchange lot of data between two tasks 
> (producer -> consumer) with some buffer in the middle. I used 
> rt_pipe/linux device scheme, but I realised that the preformance is 
> very low. (At least some performance monitor showed it)

Could you elaborate on this? Does the performance monitor (which one?)
tell you more details? What is the characteristic of your transferred
data (size, frequency)?

> So I tried to use rt_queue. But when I tried to read from queue with
> timeout (or TM_INFINITE), I got an EPERM error. That means: "service
> should block, but was called from a context, which cannot sleep.".
> But I want to sleep (and wait for new data). Where is the problem? Do
> you have any advice?

Is the read of the queue a Xenomai thread? It has to be, even if it will
mostly run in secondary (Linux) mode. Check also /proc/xenomai/sched
when you think it should be.

Maybe what you really want is shared memory between producer and
consumer. If the consumer is mapped to Xenomai, you can even use normal
synchronisation (mutexes/semaphores) to control the access - or design
something lock-less.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Petr Cervenka]

>Petr Cervenka wrote:
>> I have Xenomai snapshot (18.5.2006, 2.1.1 ~ 2.1.2) and userspace 
>> application. I need to exchange lot of data between two tasks 
>> (producer -> consumer) with some buffer in the middle. I used 
>> rt_pipe/linux device scheme, but I realised that the preformance is 
>> very low. (At least some performance monitor showed it)
>
>Could you elaborate on this? Does the performance monitor (which one?)
>tell you more details? What is the characteristic of your transferred
>data (size, frequency)?
performace editor: KSysGuard, graphs of System Load and User Load
Frequency: 10000Hz(100us period), cca 50-100bytes
I tried to remove the pipe. The producer didn't send data in pipe and the consumer was synchronized by timer instead of read from pipe. The cpu load was much lower (50+% -> 10-%).

>
>> So I tried to use rt_queue. But when I tried to read from queue with
>> timeout (or TM_INFINITE), I got an EPERM error. That means: "service
>> should block, but was called from a context, which cannot sleep.".
>> But I want to sleep (and wait for new data). Where is the problem? Do
>> you have any advice?
>
>Is the read of the queue a Xenomai thread? It has to be, even if it will
>mostly run in secondary (Linux) mode. Check also /proc/xenomai/sched
>when you think it should be.
Both tasks are created by rt_task_create and started by rt_task_start. They are also in /proc/xenomai/sched:
CPU  PID    PRI      TIMEOUT  STAT       NAME
  0  0       -1      0        R          ROOT/0
  1  0       -1      0        R          ROOT/1
  1  313     20      0        X          main_task
  1  314     30      30195788906 w          hw_task
Note: I'm still using your patch allowing to call rtdm_event_timedwait even in nrt.

>Maybe what you really want is shared memory between producer and
>consumer. If the consumer is mapped to Xenomai, you can even use normal
>synchronisation (mutexes/semaphores) to control the access - or design
>something lock-less.
I think, that pipes or queues are exactly what I need (FIFO). Every atempt to use shared memory and synchronization will probably bring only more errors made by myself.

Petr

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Philippe Gerum]

On Thu, 2006-08-03 at 16:28 +0200, Petr Cervenka wrote:
> >Petr Cervenka wrote:
> >> I have Xenomai snapshot (18.5.2006, 2.1.1 ~ 2.1.2) and userspace 
> >> application. I need to exchange lot of data between two tasks 
> >> (producer -> consumer) with some buffer in the middle. I used 
> >> rt_pipe/linux device scheme, but I realised that the preformance is 
> >> very low. (At least some performance monitor showed it)
> >
> >Could you elaborate on this? Does the performance monitor (which one?)
> >tell you more details? What is the characteristic of your transferred
> >data (size, frequency)?
> performace editor: KSysGuard, graphs of System Load and User Load
> Frequency: 10000Hz(100us period), cca 50-100bytes
> I tried to remove the pipe. The producer didn't send data in pipe and the consumer was synchronized by timer instead of read from pipe. The cpu load was much lower (50+% -> 10-%).
> 

I'm not sure to understand which kind of impact you would expect from an
IPC that does at the very least a kernel-to-user copy of the transmitted
data, but also crosses boundaries between RT and non-RT domains.

This said, I agree that queues are likely the best way to exchange large
amount of data between RT tasks, specifically if you can prepare the
largest possible data bulks to be sent in place (i.e. directly in the
transmission buffer obtained by rt_queue_alloc), so that there is no
other copy needed for transmission.

> >
> >> So I tried to use rt_queue. But when I tried to read from queue with
> >> timeout (or TM_INFINITE), I got an EPERM error. That means: "service
> >> should block, but was called from a context, which cannot sleep.".
> >> But I want to sleep (and wait for new data). Where is the problem? Do
> >> you have any advice?
> >
> >Is the read of the queue a Xenomai thread? It has to be, even if it will
> >mostly run in secondary (Linux) mode. Check also /proc/xenomai/sched
> >when you think it should be.
> Both tasks are created by rt_task_create and started by rt_task_start. They are also in /proc/xenomai/sched:
> CPU  PID    PRI      TIMEOUT  STAT       NAME
>   0  0       -1      0        R          ROOT/0
>   1  0       -1      0        R          ROOT/1
>   1  313     20      0        X          main_task
>   1  314     30      30195788906 w          hw_task
> Note: I'm still using your patch allowing to call rtdm_event_timedwait even in nrt.
> 
> >Maybe what you really want is shared memory between producer and
> >consumer. If the consumer is mapped to Xenomai, you can even use normal
> >synchronisation (mutexes/semaphores) to control the access - or design
> >something lock-less.
> I think, that pipes or queues are exactly what I need (FIFO). Every atempt to use shared memory and synchronization will probably bring only more errors made by myself.
> 
> Petr
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Petr Cervenka wrote:
>>> So I tried to use rt_queue. But when I tried to read from queue with
>>> timeout (or TM_INFINITE), I got an EPERM error. That means: "service
>>> should block, but was called from a context, which cannot sleep.".
>>> But I want to sleep (and wait for new data). Where is the problem? Do
>>> you have any advice?
>> Is the read of the queue a Xenomai thread? It has to be, even if it will
>> mostly run in secondary (Linux) mode. Check also /proc/xenomai/sched
>> when you think it should be.
> Both tasks are created by rt_task_create and started by rt_task_start. They are also in /proc/xenomai/sched:
> CPU  PID    PRI      TIMEOUT  STAT       NAME
>   0  0       -1      0        R          ROOT/0
>   1  0       -1      0        R          ROOT/1
>   1  313     20      0        X          main_task
>   1  314     30      30195788906 w          hw_task
> Note: I'm still using your patch allowing to call rtdm_event_timedwait even in nrt.

The only thing I can recommend here: try reducing your code to the bare
minimum that still demonstrate the issue, then post it.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Petr Cervenka]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

>
>Petr Cervenka wrote:
>>>> So I tried to use rt_queue. But when I tried to read from queue with
>>>> timeout (or TM_INFINITE), I got an EPERM error. That means: "service
>>>> should block, but was called from a context, which cannot sleep.".
>>>> But I want to sleep (and wait for new data). Where is the problem?
Do>>> you have any advice?
>>> Is the read of the queue a Xenomai thread? It has to be, even if it
will
>>> mostly run in secondary (Linux) mode. Check also /proc/xenomai/sched
>>> when you think it should be.
>> Both tasks are created by rt_task_create and started by rt_task_start.
They are also in /proc/xenomai/sched:
>> CPU PID PRI TIMEOUT STAT NAME
>> 0 0 -1 0 R ROOT/0
>> 1 0 -1 0 R ROOT/1
>> 1 313 20 0 X main_task
>> 1 314 30 30195788906 w hw_task
>> Note: I'm still using your patch allowing to call rtdm_event_timedwait
even in nrt.
>
>The only thing I can recommend here: try reducing your code to the bare
>minimum that still demonstrate the issue, then post it.
>

I made a reduced example and the error was still there. So I tried a couple of things and I found out, that new interface rt_queue_write/rt_queue_read is faulty (perhaps only rt_queue_read) or I misused it. I used these functions to speed up the trasfer from rt_pipes/linux devices. "Zero-copy" optimization should come somewhere in near future (or never) ;-)
When I tried to use rt_queue_alloc/rt_queue_send/rt_queue_receive/rt_queue_free, everything was fine.
Xenomai version: 2.2.0 with any patches
Linux: 2.6.17.7, adeos: 2.6.17-i386-1.3-09
Petr


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: queuetest.cpp --]
[-- Type: text/x-c++src; name="queuetest.cpp", Size: 4864 bytes --]

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

//#include <stdexcept>
//#include <unistd.h>

#include <signal.h>		//signal
#include <sys/mman.h>	//mlockall, MCL_CURRENT, MCL_FUTURE

#include <native/task.h>
#include <native/queue.h>

// CXXFLAGS:
//    -D_REENTRANT -Wall -pipe -I/usr/src/linux/include -I/usr/xenomai/include
// LDFLAGS:
//     -lnative -L/usr/xenomai/lib
// old compile options flag

#define USE_READ_WRITE

#define PERIOD				10000000	//10ms
//#define PERIOD				100000	//100us
#define QUEUE_INPUT_LEN		1024
#define CPU_ID				0

RT_TASK task_main, task_producer, task_consumer;
RT_QUEUE queue_input;
void *cookie = NULL;
static volatile bool finished = false;

struct TInputData {
	int counter;
	int data[16];
};

static void sighandler(int dummy) { finished = true; }

void producer(void *cookie) {
	TInputData sendData;
	memset(&sendData, 0, sizeof(TInputData));
	while(!finished) {
		rt_task_wait_period(NULL);
#ifdef USE_READ_WRITE
		int bytesSent = rt_queue_write(&queue_input, &sendData, sizeof(TInputData), Q_NORMAL);
		if (bytesSent <= 0) {
			printf("rt_queue_write(queue_input) failed: %d\n", bytesSent);
			finished = true; continue;
		}
#else
		void *msg = rt_queue_alloc(&queue_input, sizeof(TInputData));
		if(msg == NULL) {
			printf("rt_queue_alloc(queue_inout, %d) failed\n", sizeof(TInputData));
			finished = true; continue;
		}
		memcpy(msg, &sendData, sizeof(TInputData));
		int bytesSent = rt_queue_send(&queue_input, msg, sizeof(TInputData), Q_NORMAL);
		if (bytesSent <= 0) {
			printf("rt_queue_send(queue_input) failed: %d\n", bytesSent);
			rt_queue_free(&queue_input, msg);
			finished = true; continue;
		}
#endif
		sendData.counter++;
	}
}

void consumer(void *cookie) {
	TInputData receiveData;
	receiveData.counter = -1;
	while(!finished) {
		int counter = receiveData.counter;
#ifdef USE_READ_WRITE
		int bytesRead = rt_queue_read(&queue_input, &receiveData, sizeof(TInputData), TM_INFINITE);
		if (bytesRead <= 0) {
			printf("rt_queue_read(queue_input) failed: %d\n", bytesRead);
			finished = true; continue;
		} 
#else
		void *msg;
		int bytesRead = rt_queue_receive(&queue_input, &msg, TM_INFINITE);
		if (bytesRead > 0) {
			memcpy(&receiveData, msg, sizeof(TInputData));
			rt_queue_free(&queue_input, msg);
		}
		if (bytesRead <=0) {
			printf("rt_queue_receive(queue_input) failed: %d\n", bytesRead);
			finished = true; continue;
		}
#endif
		else if (receiveData.counter != counter + 1) {
			printf("counter error: %d\t->\t%d\n", counter + 1, receiveData.counter);
		} else {
			printf("%d\n", receiveData.counter);
		}
	}
}

int main(int argc, char *argv[])
{
	int res;
	res = mlockall(MCL_CURRENT | MCL_FUTURE);
	if (res < 0) {
		printf("mlockall failed: %d\n", res);
		goto exit;
	}
	
	//MAIN
	res = rt_task_shadow(
		&task_main,				// task descriptor
		"main",					// task name
		10,						// priority
		T_FPU | T_CPU(CPU_ID)	// mode T_FPU, T_CPU(i), T_SUSP
	);
	if (res < 0) {
		printf("rt_task_shadow(task_main) failed: %d\n", res);
		goto cleanup_main;
	}

	// INPUT_QUEUE
	res = rt_queue_create(&queue_input, "queue_input", sizeof(TInputData) * QUEUE_INPUT_LEN,
		QUEUE_INPUT_LEN, Q_FIFO | Q_SHARED);
	if (res == -EEXIST)  {
		res = rt_queue_bind(&queue_input, "queue_input", 1000);
		//rt_queue_clear(&queue_input);
	}
	if (res < 0) {
		printf("rt_queue_create(queue_input) failed: %d\n", res);
		goto cleanup_queue_input;
	}

	// CONSUMER
	res = rt_task_create(
		&task_consumer,					// task descriptor
		"consumer",						// task name
		512*1024,						// stack size
		20,								// priority
		T_FPU | T_CPU(CPU_ID) | T_JOINABLE	// mode T_FPU, T_CPU(i), T_SUSP
		);
	if (res < 0) {
		printf("rt_task_create(consumer) failed: %d\n", res);
		goto cleanup_consumer;
	}

	// PRODUCER
	res = rt_task_create(
		&task_producer,					// task descriptor
		"producer",						// task name
		256*1024,						// stack size
		30,								// priority
		T_FPU | T_CPU(CPU_ID) | T_JOINABLE	// mode T_FPU, T_CPU(i), T_SUSP
		);
	if (res < 0) {
		printf("rt_task_create(producer) failed: %d\n", res);
		goto cleanup_producer;
	}

	res = rt_task_start(&task_consumer, consumer, cookie);

	rt_task_set_periodic(
		&task_producer,
		rt_timer_read() + 5 * rt_timer_ns2ticks(PERIOD),
		rt_timer_ns2ticks(PERIOD)
	);
	res = rt_task_start(&task_producer, producer, cookie);

	signal(SIGINT, sighandler);
	signal(SIGTERM, sighandler);
	signal(SIGHUP, sighandler);
	signal(SIGALRM, sighandler);

	while(!finished)
		pause();

	printf("cleanup(producer)\n");
	rt_task_unblock(&task_producer);
	rt_task_join(&task_producer);
cleanup_producer:
	printf("cleanup(consumer)\n");
	rt_task_unblock(&task_consumer);
	rt_task_join(&task_consumer);
cleanup_consumer:
	printf("cleanup(queue_input)\n");
	rt_queue_delete(&queue_input);
cleanup_queue_input:
cleanup_main:
exit:

	if (res >= 0)
		return EXIT_SUCCESS;
	else
		return res;
}

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

Petr Cervenka wrote:

> ...
> I made a reduced example and the error was still there. So I tried a couple of things and I found out, that new interface rt_queue_write/rt_queue_read is faulty (perhaps only rt_queue_read) or I misused it. I used these functions to speed up the trasfer from rt_pipes/linux devices. "Zero-copy" optimization should come somewhere in near future (or never) ;-)
> When I tried to use rt_queue_alloc/rt_queue_send/rt_queue_receive/rt_queue_free, everything was fine.
> Xenomai version: 2.2.0 with any patches
> Linux: 2.6.17.7, adeos: 2.6.17-i386-1.3-09
> Petr
>
>   
I quick run of your program confirmed that there is something fishy:

[  277.130780] Xenomai: Switching consumer to secondary mode after exception #14 in kernel-space at 0xc01cb6dc (pid 907)
[  277.131489] I-pipe tracer log (30 points):
[  277.131571] func                    0 ipipe_trace_panic_freeze+0x8 (xnpod_fault_handler+0xe1)
[  277.131757] func                  -15 xnpod_fault_handler+0xd (xnpod_trap_fault+0x32)
[  277.131921] func                  -29 xnpod_trap_fault+0x8 (xnarch_trap_fault+0x1f)
[  277.132083] func                  -35 xnarch_trap_fault+0xb (exception_event+0x2d)
[  277.132347] func                  -46 exception_event+0x9 (__ipipe_dispatch_event+0x5e)
[  277.132547] func                  -50 __ipipe_dispatch_event+0xe (__ipipe_handle_exception+0x4d)
[  277.132746] func                  -54 __ipipe_handle_exception+0xb (error_code+0x54)
[  277.132937] func                  -68 __copy_from_user_ll+0xa (__rt_queue_read+0x87)
[  277.133128] func                  -81 __ipipe_restore_pipeline_head+0x8 (xnregistry_fetch+0x79)
[  277.133326] func                  -83 xnregistry_fetch+0x9 (__rt_queue_read+0x44)
[  277.133515] func                  -87 __copy_from_user_ll+0xa (__rt_queue_read+0x3c)
[  277.133855] func                  -96 __rt_queue_read+0xe (hisyscall_event+0x140)
[  277.134047] func                 -107 hisyscall_event+0xe (__ipipe_dispatch_event+0x5e)
[  277.134241] func                 -108 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x55)
[  277.134437] func                 -110 __ipipe_syscall_root+0x9 (system_call+0x20)
[  277.134626] func                 -172 ipipe_unstall_pipeline_head+0x8 (xnshadow_harden+0x118)
[  277.134823] func                 -178 xnpod_switch_fpu+0xa (xnshadow_harden+0x105)
[  277.135012] func                 -181 __switch_to+0xe (schedule+0x4b2)

Philippe, can you comment on this?

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Philippe Gerum]

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

On Sat, 2006-08-05 at 18:50 +0200, Jan Kiszka wrote:
> Petr Cervenka wrote:
> 
> > ...
> > I made a reduced example and the error was still there. So I tried a couple of things and I found out, that new interface rt_queue_write/rt_queue_read is faulty (perhaps only rt_queue_read) or I misused it. I used these functions to speed up the trasfer from rt_pipes/linux devices. "Zero-copy" optimization should come somewhere in near future (or never) ;-)
> > When I tried to use rt_queue_alloc/rt_queue_send/rt_queue_receive/rt_queue_free, everything was fine.
> > Xenomai version: 2.2.0 with any patches
> > Linux: 2.6.17.7, adeos: 2.6.17-i386-1.3-09
> > Petr
> >
> >   
> I quick run of your program confirmed that there is something fishy:
> 
> [  277.130780] Xenomai: Switching consumer to secondary mode after exception #14 in kernel-space at 0xc01cb6dc (pid 907)
> [  277.131489] I-pipe tracer log (30 points):
> [  277.131571] func                    0 ipipe_trace_panic_freeze+0x8 (xnpod_fault_handler+0xe1)
> [  277.131757] func                  -15 xnpod_fault_handler+0xd (xnpod_trap_fault+0x32)
> [  277.131921] func                  -29 xnpod_trap_fault+0x8 (xnarch_trap_fault+0x1f)
> [  277.132083] func                  -35 xnarch_trap_fault+0xb (exception_event+0x2d)
> [  277.132347] func                  -46 exception_event+0x9 (__ipipe_dispatch_event+0x5e)
> [  277.132547] func                  -50 __ipipe_dispatch_event+0xe (__ipipe_handle_exception+0x4d)
> [  277.132746] func                  -54 __ipipe_handle_exception+0xb (error_code+0x54)
> [  277.132937] func                  -68 __copy_from_user_ll+0xa (__rt_queue_read+0x87)
> [  277.133128] func                  -81 __ipipe_restore_pipeline_head+0x8 (xnregistry_fetch+0x79)
> [  277.133326] func                  -83 xnregistry_fetch+0x9 (__rt_queue_read+0x44)
> [  277.133515] func                  -87 __copy_from_user_ll+0xa (__rt_queue_read+0x3c)
> [  277.133855] func                  -96 __rt_queue_read+0xe (hisyscall_event+0x140)
> [  277.134047] func                 -107 hisyscall_event+0xe (__ipipe_dispatch_event+0x5e)
> [  277.134241] func                 -108 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x55)
> [  277.134437] func                 -110 __ipipe_syscall_root+0x9 (system_call+0x20)
> [  277.134626] func                 -172 ipipe_unstall_pipeline_head+0x8 (xnshadow_harden+0x118)
> [  277.134823] func                 -178 xnpod_switch_fpu+0xa (xnshadow_harden+0x105)
> [  277.135012] func                 -181 __switch_to+0xe (schedule+0x4b2)
> 
> Philippe, can you comment on this?
> 

Not really, just "gasp..."

-- 
Philippe.


[-- Attachment #2: fix-timeout-arg.patch --]
[-- Type: text/x-patch, Size: 529 bytes --]

Index: ksrc/skins/native/syscall.c
===================================================================
--- ksrc/skins/native/syscall.c	(revision 1406)
+++ ksrc/skins/native/syscall.c	(working copy)
@@ -2430,7 +2430,7 @@
 	    (curr, VERIFY_READ, __xn_reg_arg4(regs), sizeof(timeout)))
 		return -EFAULT;
 
-	__xn_copy_from_user(curr, &timeout, (void __user *)__xn_reg_arg3(regs),
+	__xn_copy_from_user(curr, &timeout, (void __user *)__xn_reg_arg4(regs),
 			    sizeof(timeout));
 
 	rsize = rt_queue_receive(q, &mbuf, timeout);

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Dmitry Adamushko]

[-- Attachment #1.1: Type: text/plain, Size: 241 bytes --]

Hello,

does this patch make a difference for you?

I haven't followed the whole conversation closely so it's just based on
Jan's trace.

Just a bit blind copy_and_past from __rt_queue_receive() I guess.


-- 
Best regards,
Dmitry Adamushko

[-- Attachment #1.2: Type: text/html, Size: 301 bytes --]

[-- Attachment #2: syscall.c.patch --]
[-- Type: text/x-patch, Size: 511 bytes --]

--- syscall-old.c	2006-08-07 14:58:28.696168000 +0200
+++ syscall.c	2006-08-07 14:58:39.308361000 +0200
@@ -2375,7 +2375,7 @@ static int __rt_queue_read(struct task_s
         (curr, VERIFY_READ, __xn_reg_arg4(regs), sizeof(timeout)))
         return -EFAULT;
 
-    __xn_copy_from_user(curr, &timeout, (void __user *)__xn_reg_arg3(regs),
+    __xn_copy_from_user(curr, &timeout, (void __user *)__xn_reg_arg4(regs),
                         sizeof(timeout));
 
     rsize = rt_queue_receive(q, &mbuf, timeout);

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 374 bytes --]

Dmitry Adamushko wrote:
> Hello,
> 
> does this patch make a difference for you?
> 
> I haven't followed the whole conversation closely so it's just based on
> Jan's trace.
> 
> Just a bit blind copy_and_past from __rt_queue_receive() I guess.
> 

I guess someone should have posted a note that the issue was fixed (see
SVN). Now it's double-fixed. :)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Philippe Gerum]

On Mon, 2006-08-07 at 15:37 +0200, Jan Kiszka wrote:
> Dmitry Adamushko wrote:
> > Hello,
> > 
> > does this patch make a difference for you?
> > 
> > I haven't followed the whole conversation closely so it's just based on
> > Jan's trace.
> > 
> > Just a bit blind copy_and_past from __rt_queue_receive() I guess.
> > 
> 
> I guess someone should have posted a note that the issue was fixed (see
> SVN).

Ok, this was not terribly explicit, but I did:
https://mail.gna.org/public/xenomai-help/2006-08/msg00086.html

>  Now it's double-fixed. :)
> 
> Jan
> 
-- 
Philippe.

Re: [Xenomai-help] rt_pipe and rt_queue problems

[Dmitry Adamushko]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Ok, this was not terribly explicit, but I did:
> https://mail.gna.org/public/xenomai-help/2006-08/msg00086.html


I haven't noticed it. I thought I'm the only person out there who sends
not-inlined patches :)

Moreover I had to trust my inner voice actually telling me that such a
simple "bug" would not have remained unfixed for 2 days.

Ok, let's consider it as a side effect of ocassional jumping in. Sorry about
this confusion.


-- 
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 788 bytes --]