[Xenomai-help] rtpipe problem not solved by 2.4.1

[Xenomai-help] rtpipe problem not solved by 2.4.1

[bite]

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

Hi,

working with 2.3.4 I have an occasional problem with rtpipe.

Writing several integers from the rt side with rt_pipe_write (..., P_NORMAL)
sometimes it happens that only the first integer can be read from non-rt.

The problem seems to be triggered by (moderately) heavy socket traffic, not
clear why.

Reading from the 2.4.1 log: "Close SMP race window in message pipe's
read-side", I decided to give it a try even if I'm not working with SMP, but
my problem persists.

It is not urgent for me, I found my way out by polling ring buffers instead
of using rtps, but I think it is worth raising the suspect that there _is_
even a non-SMP race condition.

Best regards,

Bite

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

Re: [Xenomai-help] rtpipe problem not solved by 2.4.1

[Jan Kiszka]

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

bite wrote:
> Hi,
> 
> working with 2.3.4 I have an occasional problem with rtpipe.
> 
> Writing several integers from the rt side with rt_pipe_write (..., P_NORMAL)
> sometimes it happens that only the first integer can be read from non-rt.
> 
> The problem seems to be triggered by (moderately) heavy socket traffic, not
> clear why.
> 
> Reading from the 2.4.1 log: "Close SMP race window in message pipe's
> read-side", I decided to give it a try even if I'm not working with SMP, but
> my problem persists.
> 
> It is not urgent for me, I found my way out by polling ring buffers instead
> of using rtps, but I think it is worth raising the suspect that there _is_
> even a non-SMP race condition.

Do you have a simple test case that can trigger the issue? That would 
help a lot to nail the problem down.

Jan


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

Re: [Xenomai-help] rtpipe problem not solved by 2.4.1

[bite]

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

>
> Hi,
>
> intentionally dropped the CC?
>

No, just an occasional gmail user. Not intuitive, at least for me. Hitting
"reply" to your message, this is what I got. (Looking again, your message
appears to have me as the only addressee, so no surprise).


> bite wrote:
> > I know, but if it was easy to do, i would already have posted an
> example.
> >
> > The problem arises in a numerical controller application having the
> > following organization:
> >
> > - rt periodic task, receiving commands thru ring buffers and sending
> replies
> > thru rtp.
> > - non-rt server working as a bridge, pending on select both for tcp/ip
> > sockets and /dev/rtp*.
> > - c++ client talking to the server thru tcp/ip sockets
> > - java user interface talking to the server thru tcp/ip sockets, too.
> >
> > The java UI asks for status information (axis position etc) about twice
> a
> > second, while the c++ client transacts only upon user request.
> >
> > No problem ever occurs when the java UI is not working.
> >
> > The problem occasionally occurs only when the java UI is up.
> >
> > You can see that it is not easy to nail down an example, sorry.
>
> An alternative to reproducing the bug on one of our systems is to debug
> it on yours, either with the help of the I-pipe tracer or with LTTng.
>
> The former marks each and ever function call inside the kernel and is
> specifically helpful to track the call history temporally close to the
> failure (the application could issue a trace freeze on detecting the
> issue).
>
> The latter, LTTng, traces at a higher level and can therefore run over a
> longer time. But it also requires some help of the application to mark
> the failure in order to find it later on in the trace log.
>
> Both methods need a specifically prepared kernels (for LTTng, I would
> have to provide some patches from my private repository, the I-pipe
> trace just needs a config switch), and both methods may need interactive
> debugging, ie. some rounds where we put additional instrumentation in
> your kernel to collect rt-pipe specific states. Would you have the time
> and motivation to work together with us on this?
>

Surely yes for the motivation. For what concerns the time, yes too, but
please leave me one week to ten days to complete my work and deliver it to
my customer, then I will be glad to cooperate.

I will inform you when ready and if I don't, please remind me.

Thank you,

Bite


Jan
>
>

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