On 2011-03-08 21:21, Vinzenz Bargsten wrote: >>>>> Smells like IRQ conflict in line 17. What devices are using it? Check >>>>> /proc/interrupt or lspci. >>>>> >>>>> >>>> The real-time nic was using IRQ 16, see >>>> >>>> Feb 28 14:37:12 robot02 kernel: [ 2700.099343] rt_8139too 0000:03:00.0: >>>> PCI->APIC IRQ transform: INT A -> IRQ 16 >>>> You are right, IRQ 16 was shared with a usb controller. >>>> >>>> As the 2nd (non-rt) 8139 nic had it's own IRQ 17, >>>> I tried to use that instead and just swapped the cables. The problem >>>> occured, too. >>>> >>>> Then I swapped the cards in the PCI slots and the situation got worse. >>>> See list of interrupts attached (interrupts.txt) >>>> >>> Both 8139 cards are of the same type. What were you steps to ensure that >>> the right driver handles the right card? >>> >> - I use the cards parameter (well, that doesn't really ensure) >> - the cards and cables are labeled (also with mac addresses) >> - If I use the wrong interface, there shouldn't be any communication since >> my >> program only uses the rt interface >> - one card's mac address is registered in the uni network, that's why I >> swapped the cards pci slot rather than just using the other one >> > The problem also occurs with only one 8139 card, which has its own irq. I > could > not reproduce the PCI Bus errors. > > I'm letting rtping running in the background, did not get that problem then > (so > far). > Maybe unrelated or a problem of the remote side, I see periodically high ping > times, see attachment.
If you have an IRQ conflict (which I still assume) but you still have valid IRQ reason at a sufficiently high rate, the system will continuously recover. Only if a large number of unhandled IRQs were received, Xenomai will disable the chatty line. > >> I also have a tulip card available, but if I remember correctly, loading the >> rt_tulip module locked up the pc. I can check again, though. >> I can also try to remove one of the 8139 nics. > The driver is loaded but no communication is possible. In wireshark 3-4 > outgoing > rtping packets show up, then rtping causes a "ioctl: No buffer space > available". > Nothing is received. The fact that two different adapter show similar issues (IRQs are not properly delivered, which will exhaust buffer resources sooner or later) indicate, that the problem is not the adapter but likely the system with its IRQ routing. > > Can someone recommend a PCI network card which works well with recent RTNet/ > kernels / hardware? I thought about a Intel Pro 1000 or 100 PCI as well as > via_rhine cards, which are also quite common. > On x86, a good way to avoid IRQ issues is to pick a recent supported card with MSI(-X) support. rt_igb is a known-to-work example. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
