Am 08.03.2011 21:59, schrieb Jan Kiszka:
> 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
The setup changed in the following way:
- I do not use any 8139too card anymore.
- Instead, I use an igb card (Intel E1G42ET); to free the PCIe-x16 slot
I use a PCI graphics card.
The problem changed in the following way:
- The communication does not stop, but I encountered a
- delayed output packet and 2 or 3 consecutive input packets are not
received (do not show up in wireshark).
I think they are on the line / sent by the remote station but it is
difficult to proove.
Actually it counts delayed (or non-answered) packets and the counter
increases to 3.
- The rtping response times are similar (maybe a bit less often), i.e.
up ~1000µs every ~100s.
Not sure if this is caused by the remote station.
What do you recommend to resolve these issues?
Thank you very much,
Vinzenz
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
