In the following setups rtcap has not worked for me: RTAI 3.8.1 Kernel 2.6.32.11 RTNet 0.9.12 RTAI 3.8 Kernel 2.6.30.5 RTNet 0.9.11
The last working setup as far as I remember: RTAI 3.7.1 Kernel 2.6.29.4 RTNet 0.9.10 So it's not easy to point on a specific version or application from this. I will try out the RTAI 3.8.1/2.6.32.11/0.9.12 setup on my laptop, if that doesn't work there either I could try to roll back to some older versions. /Henrik On 08/05/2010 20:52 "Jan Kiszka" <jan.kis...@web.de> wrote: > Henrik Slotholt wrote: > > Hi, > > > > Please find attached the rtcap_panic serial console dump. I have > > tried a > > lot of different setups lately, but as far as I remember the latest > > stable rtcap I has been using was Ubuntu 9.04 RTAI 3.7.1 kernel > > 2.6.29.4. > > Does the RTAI/kernel version make the difference here or the RTnet > version (or git revision)? > > > > > Thanks a lot for your answers so far. I hope the dump can give you a > > clue of the problem. > > Not yet. Maybe we see an early shot of the rtcap_signal_handler, maybe > it's a so far undiscovered race. > > Can you retry with CONFIG_FRAME_POINTERS enabled, and maybe also > CONFIG_IPIPE_TRACE_MCOUNT (selects frame pointers automatically)? The > latter may provide a better picture of what happened before the crash > (increase /proc/ipipe/trace/back_trace_points to, say, 1000 before > triggering the oops.) > > Thanks, > Jan > >
------------------------------------------------------------------------------
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users