Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Hi Jan, >> >> 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. >>> >>> 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). >> I will try to reporduce the problem a.s.a.p. > > TiA.
Grmbl. You can forget about it, I found the magic knob. Normally I don't even notice that the tracer is running in background. This time I did notice it, but didn't realised that it was the reason. Already disabling it during runtime "solves" my problem. It looks like its overhead combined with a few more debug options of Linux, the high IRQ load, and a low-end board drove the otherwise only moderately loaded box into starvation. Sorry for making noise, let's go back to business. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
