You are right that should read 0.9.11 instead of 0.9.10. I have been using 0.9.10 with RTAI 3.6-cv.
On 09/05/2010 13:10 "Jan Kiszka" <jan.kis...@web.de> wrote: > Henrik Slotholt wrote: > > 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 > > You either confused the RTnet version or used a git snapshot, but > 2.6.29 > required e233d99c50a5565583e8c39a592f6547974dc530, and that came with > 0.9.11. > > > > > 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. > > I'm specifically interested in checking the RTnet versions. If you can > reproduce the issue with latest RTnet on an older RTAI/kernel basis, > then we would have a first trace that it's an RTnet regression. > > However, /me is also still interested in the tracer output as it may > visualize what goes wrong directly (even if we know what change caused > the regression, we still need to understand why). > > Jan > > > > > /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
