Il 06/10/21 13:30, Mauro S. via Xenomai ha scritto:
Il 06/10/21 12:26, Jan Kiszka ha scritto:
On 06.10.21 09:00, Jan Kiszka via Xenomai wrote:
On 05.10.21 18:00, Jan Kiszka via Xenomai wrote:
On 25.09.21 18:20, Mauro S. via Xenomai wrote:
Hi all,

I'm using Xenomai 3.1.1 in cobalt mode, on x84_64.

Please consider the attached simple test code.

When I start the application, I never see the "Pipe task running" printf.

When I close application (ctrl+c), rt_pipe_join() on pipe task hangs.

Analyzing the code with gdb, the timeout in tv structure inside
rt_pipe_read_timed() is the following

(gdb) thread 13
[Switching to thread 13 (Thread 0x7ffff7189700 (LWP 528))]
#0  0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
250    rtdm.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7f89471 in do_recvmsg (fd=fd@entry=3,
msg=msg@entry=0x7ffff7188c40, flags=flags@entry=0) at rtdm.c:250
#1  0x00007ffff7f89e11 in __cobalt_recvfrom (fd=3,
buf=buf@entry=0x7ffff7188d60, len=len@entry=4, flags=0,
from=from@entry=0x0,
     fromlen=fromlen@entry=0x0) at rtdm.c:343
#2  0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
     at pipe.c:423
#3  0x00005555555555c0 in rt_pipe_read (pipe=0x555555558150 <MyPipe>,
buf=0x7ffff7188d60, size=4, timeout=500000)
     at
/opt/smitec/3.1.5_SDK/sysroots/corei7-64-poky-linux/usr/include/xenomai/alchemy/pipe.h:72

#4  0x00005555555556d4 in MyPipeFun (arg=0x0) at test_resume_pipe.c:55
#5  0x00007ffff7fc196a in task_entry (arg=0x7ffff732ddc8) at task.c:237
#6  task_entry (arg=0x7ffff732ddc8) at task.c:219
#7  0x00007ffff7faaca9 in thread_trampoline
(arg=arg@entry=0x7fffffffe9c0) at internal.c:251
#8  0x00007ffff7f8b93e in cobalt_thread_trampoline (p=0x7fffffffe820) at
thread.c:123
#9  0x00007ffff7f58ea4 in start_thread (arg=<optimized out>) at
pthread_create.c:477
#10 0x00007ffff7e7edcf in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) frame 2
#2  0x00007ffff7fc38ab in rt_pipe_read_timed (pipe=<optimized out>,
buf=0x7ffff7188d60, size=4, abs_timeout=<optimized out>)
     at pipe.c:423
423    pipe.c: No such file or directory.
(gdb) print tv
$1 = {tv_sec = 1438, tv_usec = 783700}

It seems a value related to uptime (system was up by about 24 minutes,
1440 seconds, when debugging).

Right, Xenomai's CLOCK_REALTIME starts at system boot, not at the epoch.
That's at least true for I-pipe deployments.


The API documentation says that rt_pipe_read() accepts "a delay
expressed in clock ticks". In Xenomai code, rt_pipe_read() becomes
rt_pipe_read_timed(), that accepts "An absolute date expressed in clock ticks", with a note saying "abs_timeout is interpreted as a multiple of the Alchemy clock resolution" (I dont' understand this latter sentence).


The Alchemy clock may not simply tick in single nanoseconds but may have
a courser resolution. That's why there is rt_timer_ns2ticks which you
are already using.

If I'm not wrong, the "absolute date" would be a date expressed in
seconds after the epoch. Could the alchemy_rel_timeout() call in
include/alchemy/pipe.h calculate a wrong timeout?
Otherwise, what could be the problem?

Cannot say yet, but I can confirm seeing the issue (too long timeout) as
well. Did you try to debug further already?


Looks like rt_pipe_read_timed is wrong: SO_RCVTIMEO takes a relative
timeout to my reading of the man page and the code, but
rt_pipe_read_timed passed down an absolute value. This confuses me
because the function was like this for ages, so I might misread
something ATM. Philippe?


It is definitely broken in alchemy, I've created
https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues/30 to track the
to-dos. Any helping hand welcome.

Jan



Hi Jan,

sorry for the delay.

Thank you for your explanations and your analysis.

Mauro


Hi Jan,

I confirm that your patchset has fixed the rt_pipe part.

Thanks, regards

--
Mauro S.

Reply via email to