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.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to