Hi Jan, > > (in fact, I have 3 interfaces on that PC: eth2 is a 3Com > > 3C905, and rteth0 and rteth1 are 8169-based interfaces) > > Oops, try to resolve this first. It is in NO WAY recommended > to share IRQs between real-time and non-real-time devices. You > may even face crashes as we recently did here with an older > RTAI version. So far, I'm not sure if the crash is due to RTAI > or a bug in RTnet, but as IRQ sharing makes no sense from the > real-time point of view anyway, we did not yet look at this > effect closer. > > Resolve the IRQ conflict first and then check if the problems > persist. If yes, please report again.
You were right, simply unloading the driver for the IRQ-sharing non-RT interface solves the problem: the RT interface has no more problems while capturing packets. However, I am still curious about the memory management issue: I believed that the drivers had separate pools of packet buffers? Aren't those pools limited in size? How is it possible that the RTAI/RTDM layer as a whole runs out of memory (and can even no more produce output for /proc/rtai/sched) ? -- Romain Lenglet ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
