Re: [RTnet-users] System-freeze while using rttcp and rtudp in parallel

[Jan K. <jan...@we...>]

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