Bruno Carlus wrote:
Bruno Carlus a écrit :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 !Jan Kiszka a écrit :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...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 qemuI 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. ;)By the way, a version of the code compiled without wrapping with xenomai/posix works fine...I don't understantd something here, because I thought everything was RT since I was compiling with the xeno-config posix flags ...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.Does sock_lock also force sendto to run in RT ?JanThanks, Bruno.
Nice to hear.
Anyway, if anyone (Jan ? ;-) ) could answer my last mail questions about RT/non RT it would still help ... !
Sendto itself will force the caller into primary mode (if it wasn't already) if and only if the socket it operates on is provided by RTnet.
Under the Xenomai POSIX skin, this is the case if you invoke socket() with a RTnet-support protocol. Unsupported protocols (e.g. TCP) or __real_socket() invocation will be passed down to Linux and succeeding sendto (or other sevices) on the related file descriptor will also be handled.
Hope that helped to clarify the mechanism. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
