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

Reply via email to