Re: [RTnet-users] System-freeze while using rttcp and rtudp in parallel
Brought to you by:
bet-frogger,
kiszka
|
From: Jan K. <jan...@we...> - 2015-06-28 14:24:52
|
On 2015-06-23 10:38, Tho...@st... wrote: > Hello everybody, > > we have a strange behavior with RTnet and need some help. > > We are using a sensor tethered via Ethernet to a rteth-NIC exclusively. > The sensor has to be configured, started and stopped with short > http-commands. For this we are using the RTnet tcp-module. > The continuous sensor-data itself are provided with UDP and for this we > are using the RTnet udp-module. > Thus far everything works fine. > > When we sent http-commands for e.g. startup to a second sensor connected > to a second rteth-NIC and the first sensor is already in continuous-data > delivering mode (UDP), the whole operating-system freezes and there is no > response anymore. So we are not able to debug anything. > This happens often, if the data-volume of the continuous-data is small, > and it crashes nearly always, if the data-volume is larger. > > In this case, both threads are running at the same cpu. We find out, when > we switch one of the threads to another cpu, everything seems to work > fine, but we have no long-term experiences yet. In addition this approach > seems to be just a work-around. Is the Xenomai watchdog enabled, to catch run-away threads? > > If you have some ideas, remarks or if you need more information, please > let me know. Thank you! There are plenty of ways to debug even such hard freezes (well, most of them). First of all, make sure you have a serial console working and the kernel reporting to it. Then these are some of your options: - NMI watchdog (should throw a backtrace after some seconds) - I-pipe and Xenomai self-checks (build-time switches - may catch lockups or illicit API uses) - step-wise instrumentation of code to narrow-down the lockup (tedious work, I know) - hardware debugger (JTAG), less common on x86 - I suspect you are on that arch - transfer of setup into QEMU/KVM, then using built-in gdbstub (works like a hardware debugger, just cheaper and faster) HTH, Jan |