Romain Lenglet wrote: > 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) ? >
So this problem persisted after the IRQ conflict resolution? Then it's
definitely a sign that some bug remains hidden, probably in the r8169
driver.
The out-of-memory warning on cat /proc/rtai/sched is very untypical and
rather indicates that the whole system got corrupted (only "normal"
kernel memory should be requested here). If just RTnet runs out of
packets, you will not get such warnings, only the ones of the driver
itself ("cannot allocate rtskb" or so). Please, try iteratively after
which step (loading the driver, configuring the interface/the capture
device, receiving first packets, ...) the bug can be observed.
Jan
signature.asc
Description: OpenPGP digital signature
