Bruno Carlus a écrit : > Jan Kiszka a écrit : >> Bruno Carlus wrote: >>> Hi, >>> >>> to test my multicast patch I tried the following piece of code, >>> simplier than the ptp soft, to validate the modifications. >>> The problem is that the packets are correctly sent and seemed to be >>> received by the rtnet udp layer at the other side, but never get to >>> the socket layer receiving ... >> >> You can >> - instrument the receiver side to find out what is happening (printk) >> - use some tracer (i-pipe tracer or lttng) >> - run the whole thing under qemu >> >> I recently did the latter before releasing 0.9.10-rc2. Works nicely >> these days as qemu now provides several of the network adapters that >> RTnet supports. Of course, timing is not reliable, BUT... you can >> debug the targets without any kernel patch or additional hardware >> support! And if something crashes, you don't have to leave your seat >> and walk to some reset switch. ;) >> > my first analysis shows that everything works fine reception-side till > the rtnet udp layer: the socket coresponding to the multicast @ is > found by rt_udp_v4_lookup function. But I don't know what happens > afterwards or where to put trace or debug printouts... > > By the way, a version of the code compiled without wrapping with > xenomai/posix works fine... >>> >>> Other thing maybe in touch when ^c the little program rtdm >>> complains: "closing device in real-time mode while creation ran in >>> non real time - this is not supported! " maybe related to my problem. >>> >>> something i did not understand about the xenomai/rtnet posix wrap? >> >> Your problem is sock_lock. It forces shutalldown into primary (=RT) >> mode before invoking close(). That neither makes sense nor works if >> socket() was invoked in secondary (=Non-RT) mode. Just gid rid of it. >> > I don't understantd something here, because I thought everything was > RT since I was compiling with the xeno-config posix flags ... > Does sock_lock also force sendto to run in RT ? >> Jan >> > > Thanks, > Bruno. > I just found out the problem, my both points above were actually linked: as the sockets weren't closing properly, a binding was still existing for rtnet; so when receiving the packets it was picking the first good binding in the list and relaying them to this old rt_sock, which wasn't linked to anything anymore "above"... I restarted everything properly (got rid of sock_lock...) and it is working with the first opened socket !
Anyway, if anyone (Jan ? ;-) ) could answer my last mail questions about RT/non RT it would still help ... ! Bruno. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
