Re: [Xenomai-core] Linux lock-up with rtcanrecv
Jan Kiszka wrote: Jan Kiszka wrote: Hi all, fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there is still a bug in trunk /wrt broken timeouts of rt_dev_read on xeno_16550A - different issue...), I ran into a weird behaviour of rtcanrecv: I have a continuous stream of a few thousand packets/s towards the robot. When I start up two rtcanrecv rtcan0 -p1000 instances (or one + our own receiver application), the second one causes a Linux lock-up. Sometimes this happens during startup of the second rtcanrecv, but at latest on its termination. Other RT tasks are still running. I can resolve the lock-up by pulling the CAN cable, everyone is fine afterwards and can be cleaned up. I played with quite a few combinations of recent ipipe patches and Xenomai revisions (even back to #1084 in v2.3.x), no noticeable difference. Forgot to mention one further observation: removing the usleep form rtcanrecv's cleanup() works around the shutdown lock-up. I can't interpret this yet. [BTW, Wolfgang, what is it good for?] Hm, I think the usleep() only make sense for rtcansend to allow messages to got out before the close. You can remove it. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Linux lock-up with rtcanrecv
Hi all,
fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
is still a bug in trunk /wrt broken timeouts of rt_dev_read on
xeno_16550A - different issue...), I ran into a weird behaviour of
rtcanrecv:
I have a continuous stream of a few thousand packets/s towards the
robot. When I start up two rtcanrecv rtcan0 -p1000 instances (or one +
our own receiver application), the second one causes a Linux lock-up.
Sometimes this happens during startup of the second rtcanrecv, but at
latest on its termination. Other RT tasks are still running. I can
resolve the lock-up by pulling the CAN cable, everyone is fine
afterwards and can be cleaned up. I played with quite a few combinations
of recent ipipe patches and Xenomai revisions (even back to #1084 in
v2.3.x), no noticeable difference.
Seems like I have to take a closer look - once time permits and the
robot is available. So any ideas or attempts to reproduce this are
welcome, current .config attached (no magic knob found there yet).
Jan
PS: Wolfgang, any objections against decoupling -v from -p and
lowering the receiver priority to 0?
Index: src/utils/can/rtcanrecv.c
===
--- src/utils/can/rtcanrecv.c (revision 2146)
+++ src/utils/can/rtcanrecv.c (working copy)
@@ -192,6 +192,7 @@ int main(int argc, char **argv)
case 'p':
print = strtoul(optarg, NULL, 0);
+ break;
case 'v':
verbose = 1;
@@ -312,7 +313,7 @@ int main(int argc, char **argv)
}
snprintf(name, sizeof(name), rtcanrecv-%d, getpid());
-ret = rt_task_shadow(rt_task_desc, name, 1, 0);
+ret = rt_task_shadow(rt_task_desc, name, 0, 0);
if (ret) {
fprintf(stderr, rt_task_shadow: %s\n, strerror(-ret));
goto failure;
config.bz2
Description: Binary data
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Linux lock-up with rtcanrecv
Jan Kiszka wrote: Hi all, fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there is still a bug in trunk /wrt broken timeouts of rt_dev_read on xeno_16550A - different issue...), I ran into a weird behaviour of rtcanrecv: I have a continuous stream of a few thousand packets/s towards the robot. When I start up two rtcanrecv rtcan0 -p1000 instances (or one + our own receiver application), the second one causes a Linux lock-up. Sometimes this happens during startup of the second rtcanrecv, but at latest on its termination. Other RT tasks are still running. I can resolve the lock-up by pulling the CAN cable, everyone is fine afterwards and can be cleaned up. I played with quite a few combinations of recent ipipe patches and Xenomai revisions (even back to #1084 in v2.3.x), no noticeable difference. Forgot to mention one further observation: removing the usleep form rtcanrecv's cleanup() works around the shutdown lock-up. I can't interpret this yet. [BTW, Wolfgang, what is it good for?] Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
