[Xenomai-help] writing from user space through fifo problems

[Xenomai-help] writing from user space through fifo problems

[NZG]

I've got 2 programs, one Xenomai user space real time thread and one normal 
user space program.

My normal user space is trying to pass a structure to my real time program and 
failing.

my RT thread reads in a 1ms loop with:
err = rt_pipe_read(control_pipe,k,sizeof(control_t),TM_NONBLOCK);

my regular linux program writes a real time fifo with:

int fd = open(dev, O_WRONLY|O_SYNC);
err = write(fd,&c,sizeof(c));
if(err<=0)error(0,-err, "write failed  with %d",err);
close(fd);

The user space program succeeds (write returns no error and doesn't block), 
but the RT thread never see's the data, continually returning -EINTR.

Note that if I change the real time thread to TM_INFINITE it works, but blocks 
for course, which isn't what I want, since I only want to pull out data at 
the beginning of a constant loop.

Is this the correct behavior? 
Does read have to be set up and waiting for the data to recieve it?

thx,
NZG

Re: [Xenomai-help] writing from user space through fifo problems

[Jan Kiszka]

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

NZG wrote:
> I've got 2 programs, one Xenomai user space real time thread and one normal 
> user space program.
> 
> My normal user space is trying to pass a structure to my real time program and 
> failing.
> 
> my RT thread reads in a 1ms loop with:
> err = rt_pipe_read(control_pipe,k,sizeof(control_t),TM_NONBLOCK);
> 
> my regular linux program writes a real time fifo with:
> 
> int fd = open(dev, O_WRONLY|O_SYNC);
> err = write(fd,&c,sizeof(c));
> if(err<=0)error(0,-err, "write failed  with %d",err);
> close(fd);
> 
> The user space program succeeds (write returns no error and doesn't block), 
> but the RT thread never see's the data, continually returning -EINTR.

Are you sure it is EINTR? A first glance at the possible code path,
specifically at xnpipe_recv, suggests that you cannot reach the line
returning this error code if TM_NONBLOCK was passed.

What Xenomai version are we talking about BTW? And, as usual:
self-contained simple test cases are always appreciated. :)

Jan


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

[Xenomai-help] Xenomai maximum latency

[ayoub zaki]

Hi all,

I've just started with Xenomai and I'm wondering if on
a given Platform does Xenomai garantee a Maximum
latency that will never be exeed ?

Regards,
zak 


      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

Re: [Xenomai-help] Xenomai maximum latency

[Gilles Chanteperdrix]

On Thu, Feb 21, 2008 at 10:39 AM, ayoub zaki <ayoub_zaki@domain.hid> wrote:
>
>  Hi all,
>
>  I've just started with Xenomai and I'm wondering if on
>  a given Platform does Xenomai garantee a Maximum
>  latency that will never be exeed ?

There is no written garantee as such. What we garantee is to do our
best to keep the maximum latency as low as possible.

And we provide the latency test, to measure the maximum latency of
your system under the load conditions you define.

-- 
 Gilles Chanteperdrix

Re: [Xenomai-help] writing from user space through fifo problems

[NZG]

> Are you sure it is EINTR? A first glance at the possible code path,
> specifically at xnpipe_recv, suggests that you cannot reach the line
> returning this error code if TM_NONBLOCK was passed.
Your right, my mistake sorry.
It's returning EAGAIN , which is the same thing as  EWOULDBLOCK in my kernel 
headers, which corresponds to the correct value when data i s not available, 
but doesn't explain why data is never received.

> What Xenomai version are we talking about BTW? 
2.3.1 (blackfin 537 build)

> And, as usual: 
> self-contained simple test cases are always appreciated. :)
I'll try to put something together tonight.

thx,
NZG

Re: [Xenomai-help] writing from user space through fifo problems

[Jan Kiszka]

NZG wrote:
>> Are you sure it is EINTR? A first glance at the possible code path,
>> specifically at xnpipe_recv, suggests that you cannot reach the line
>> returning this error code if TM_NONBLOCK was passed.
> Your right, my mistake sorry.
> It's returning EAGAIN , which is the same thing as  EWOULDBLOCK in my kernel 
> headers, which corresponds to the correct value when data i s not available, 
> but doesn't explain why data is never received.

OK, that makes more sense.

> 
>> What Xenomai version are we talking about BTW? 
> 2.3.1 (blackfin 537 build)
> 
>> And, as usual: 
>> self-contained simple test cases are always appreciated. :)
> I'll try to put something together tonight.

That's good. This test will also allow you to check it against
 - more recent Xenomai (please check the Changelog for pipe-related
   changes since 2.3.1, I bet there are a few)
 - some other arch, specifically x86 (IIRC, there is still some Linux
   scheduling artifact left in the I-pipe patch for blackfin, but it
   shouldn't make a difference here - well, who knows...)

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-help] writing from user space through fifo problems

[NZG]

On Thursday 21 February 2008 10:23:15 am Jan Kiszka wrote:
> That's good. This test will also allow you to check it against
>  - more recent Xenomai (please check the Changelog for pipe-related
>    changes since 2.3.1, I bet there are a few)
>  - some other arch, specifically x86 (IIRC, there is still some Linux
>    scheduling artifact left in the I-pipe patch for blackfin, but it
>    shouldn't make a difference here - well, who knows...)
Well, in the process of writing a simple test I kindof found the problem.
My user space program is writing and then immediatly closing, which appears to 
destroy the data if it hasn't been read by then. Inserting a sleep between 
write and close causes it to work.

I noticed this because my test program was working because it just so happened 
to pause until the real time task ended before closing the fd.

I remember doing this before, now that it's figured out, but it's still kind 
of problematic because it doesn't appear to be possible to block on user 
space writes.

Opening with O_SYNC does not cause it to block, and fsync(fd) doesn't seem to 
do anything. anybody have any suggestions on how to know data has been 
received before closing a pipe after a write? Surely somebody's done this 
before.

thanks,
NZG

Re: [Xenomai-help] writing from user space through fifo problems

[Philippe Gerum]

NZG wrote:
> On Thursday 21 February 2008 10:23:15 am Jan Kiszka wrote:
>> That's good. This test will also allow you to check it against
>>  - more recent Xenomai (please check the Changelog for pipe-related
>>    changes since 2.3.1, I bet there are a few)
>>  - some other arch, specifically x86 (IIRC, there is still some Linux
>>    scheduling artifact left in the I-pipe patch for blackfin, but it
>>    shouldn't make a difference here - well, who knows...)
> Well, in the process of writing a simple test I kindof found the problem.
> My user space program is writing and then immediatly closing, which appears to 
> destroy the data if it hasn't been read by then. Inserting a sleep between 
> write and close causes it to work.
>

Yes, releasing a fildes flushes the input queue from lingering data
before closing the user-space side.

> I noticed this because my test program was working because it just so happened 
> to pause until the real time task ended before closing the fd.
> 
> I remember doing this before, now that it's figured out, but it's still kind 
> of problematic because it doesn't appear to be possible to block on user 
> space writes.
> 
> Opening with O_SYNC does not cause it to block, and fsync(fd) doesn't seem to 
> do anything.

O_SYNC support has to be implemented by the driver, and Xenomai
implements this for the pipe driver since 2.4-rc1. Therefore, passing
O_SYNC to open() using 2.3.1 will just lead to a nop.

 anybody have any suggestions on how to know data has been
> received before closing a pipe after a write? Surely somebody's done this 
> before.
> 

The only way I see with 2.3.1 would be to make a non-realtime shadow
from your user-space thread (rt_task_shadow() with priority 0), then
have it pend on a Xenomai semaphore signaled by your real-time task when
it has consumed the packet.

> thanks,
> NZG
> 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 
Philippe.

Re: [Xenomai-help] writing from user space through fifo problems

[NZG]

On Friday 22 February 2008 3:55:42 am Philippe Gerum wrote:
> O_SYNC support has to be implemented by the driver, and Xenomai
> implements this for the pipe driver since 2.4-rc1. Therefore, passing
> O_SYNC to open() using 2.3.1 will just lead to a nop.
Ah, well then first thing to try is to just upgrade Xenomai.
I'll give it a shot, 

thanks for confirming this,
NZG

Re: [Xenomai-help] writing from user space through fifo problems

[Gilles Chanteperdrix]

On Fri, Feb 22, 2008 at 3:45 AM, NZG <metalninjadragon@domain.hid> wrote:
> On Thursday 21 February 2008 10:23:15 am Jan Kiszka wrote:
>  > That's good. This test will also allow you to check it against
>  >  - more recent Xenomai (please check the Changelog for pipe-related
>  >    changes since 2.3.1, I bet there are a few)
>  >  - some other arch, specifically x86 (IIRC, there is still some Linux
>  >    scheduling artifact left in the I-pipe patch for blackfin, but it
>  >    shouldn't make a difference here - well, who knows...)
>  Well, in the process of writing a simple test I kindof found the problem.
>  My user space program is writing and then immediatly closing, which appears to
>  destroy the data if it hasn't been read by then. Inserting a sleep between
>  write and close causes it to work.
>
>  I noticed this because my test program was working because it just so happened
>  to pause until the real time task ended before closing the fd.
>
>  I remember doing this before, now that it's figured out, but it's still kind
>  of problematic because it doesn't appear to be possible to block on user
>  space writes.
>
>  Opening with O_SYNC does not cause it to block, and fsync(fd) doesn't seem to
>  do anything. anybody have any suggestions on how to know data has been
>  received before closing a pipe after a write? Surely somebody's done this
>  before.

Well, I do not know the details of the rt_pipe implementation, but
intuitively I would say that what you observe is not normal: when you
write to the rt_pipe, the reader should be woken up immediately and
consume the data, before the producer can close the descriptor. Are
you writing data to the pipe from an RT task ?

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] writing from user space through fifo problems

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> On Fri, Feb 22, 2008 at 3:45 AM, NZG <metalninjadragon@domain.hid> wrote:
>> On Thursday 21 February 2008 10:23:15 am Jan Kiszka wrote:
>>  > That's good. This test will also allow you to check it against
>>  >  - more recent Xenomai (please check the Changelog for pipe-related
>>  >    changes since 2.3.1, I bet there are a few)
>>  >  - some other arch, specifically x86 (IIRC, there is still some Linux
>>  >    scheduling artifact left in the I-pipe patch for blackfin, but it
>>  >    shouldn't make a difference here - well, who knows...)
>>  Well, in the process of writing a simple test I kindof found the problem.
>>  My user space program is writing and then immediatly closing, which appears to
>>  destroy the data if it hasn't been read by then. Inserting a sleep between
>>  write and close causes it to work.
>>
>>  I noticed this because my test program was working because it just so happened
>>  to pause until the real time task ended before closing the fd.
>>
>>  I remember doing this before, now that it's figured out, but it's still kind
>>  of problematic because it doesn't appear to be possible to block on user
>>  space writes.
>>
>>  Opening with O_SYNC does not cause it to block, and fsync(fd) doesn't seem to
>>  do anything. anybody have any suggestions on how to know data has been
>>  received before closing a pipe after a write? Surely somebody's done this
>>  before.
> 
> Well, I do not know the details of the rt_pipe implementation, but
> intuitively I would say that what you observe is not normal: when you
> write to the rt_pipe, the reader should be woken up immediately and
> consume the data, before the producer can close the descriptor. Are
> you writing data to the pipe from an RT task ?
> 

As far as I understand, the reader polls, so userland may close the
fildes before the real-time task peeks at its pipe end.

-- 
Philippe.

Re: [Xenomai-help] writing from user space through fifo problems

[Gilles Chanteperdrix]

On Fri, Feb 22, 2008 at 10:19 AM, Philippe Gerum
<philippe.gerum@domain.hid> wrote:
>
> Gilles Chanteperdrix wrote:
>  > On Fri, Feb 22, 2008 at 3:45 AM, NZG <metalninjadragon@domain.hid> wrote:
>  >> On Thursday 21 February 2008 10:23:15 am Jan Kiszka wrote:
>  >>  > That's good. This test will also allow you to check it against
>  >>  >  - more recent Xenomai (please check the Changelog for pipe-related
>  >>  >    changes since 2.3.1, I bet there are a few)
>  >>  >  - some other arch, specifically x86 (IIRC, there is still some Linux
>  >>  >    scheduling artifact left in the I-pipe patch for blackfin, but it
>  >>  >    shouldn't make a difference here - well, who knows...)
>  >>  Well, in the process of writing a simple test I kindof found the problem.
>  >>  My user space program is writing and then immediatly closing, which appears to
>  >>  destroy the data if it hasn't been read by then. Inserting a sleep between
>  >>  write and close causes it to work.
>  >>
>  >>  I noticed this because my test program was working because it just so happened
>  >>  to pause until the real time task ended before closing the fd.
>  >>
>  >>  I remember doing this before, now that it's figured out, but it's still kind
>  >>  of problematic because it doesn't appear to be possible to block on user
>  >>  space writes.
>  >>
>  >>  Opening with O_SYNC does not cause it to block, and fsync(fd) doesn't seem to
>  >>  do anything. anybody have any suggestions on how to know data has been
>  >>  received before closing a pipe after a write? Surely somebody's done this
>  >>  before.
>  >
>  > Well, I do not know the details of the rt_pipe implementation, but
>  > intuitively I would say that what you observe is not normal: when you
>  > write to the rt_pipe, the reader should be woken up immediately and
>  > consume the data, before the producer can close the descriptor. Are
>  > you writing data to the pipe from an RT task ?
>  >
>
>  As far as I understand, the reader polls, so userland may close the
>  fildes before the real-time task peeks at its pipe end.

Ok, forgot that point.

-- 
                                               Gilles Chanteperdrix