>>>> I have an issue with rt_igb not working with an Intel I210 on ARM
>>>> (see system configuration below).
>>>> With Wireshark, looks like rtping is sending garbage on the network
>>>> (see below).
>>>> I notice there is no interrupt in /proc/xenomai/irq (see below).
>>>> Looks like other people got issues with I210 in the past but I am
>>>> not sure if they were similar and I am not able to find any conclusion.
>>>>
>>>> Below, I show you how I am inserting the kernel module + how I am
>>>> able to have it working with igb (no realtime) and rt_fec (different
>>>> driver for the other Ethernet controller on the same board).
>>>>
>>>> What can I do to solve this issue?
>>>> Is there anything else I can try to give you more data?
>>>>
>>> Could you check if that card works in a standard PC (x86-64) with RTnet?
>>> Could you also check if latest 3.2.1 makes any difference? Not all
>>> fixes on RTnet have been backported to very-old-stable.
>>>
>>> Jan
>>
>> Sorry for the delay, I needed to update my Linux kernel
>> (Freescale/linux-fslc) from version 4.9.67 to version 5.4.147 to be
>> able to compile Xenomai 3.2.1. I am still using I-pipe, not Dovetail, right?
>
> Yes, everything up to and including 5.4 is I-pipe, 5.10 and later is dovetail.
>
>> I notice that the type of interruption changed since the previous version:
>> we now have "Using MSI-X interrupts" instead of "Using MSI interrupts".
>
> Maybe the host controller of your SoC gained MSI-X support betwen 4.9 and
> 5.4? Then both the standard driver and rt_igb would try to use that instead
> (MSI is legacy).
>
>> And there is this new error: "Error 2 getting interrupt" which
>> prevents to have rteth0 configured (see below). That's different from last
> time.
>> I notice that the driver igb itself does not work with the new Xenomai
>> kernel (see below). That's also different from last time. I confirmed
>> that it works with the non-xenomai kernel though (same kernel 5.4.147
>> without the I-pipe patch).
>
> 5.4.147 - that is no official ipipe-arm release. Did you integrate the patch
> yourself base on which I-pipe core revision? And how about ipipe-core-
> 5.4.151-arm-4?
Hello Jan, all,
What I "always" did for kernels linux-fslc-imx
4.1.38 (Yocto Morty),
4.9.67 (Yocto Thud)
and 5.4.147 (Yocto Dunfell)
is that I tried to apply the closest arm I-pipe patch as possible:
- Given an example, I used ipipe-core-5.4.151-arm-4.patch to patch
Yocto Dunfell.
- Then, I manually resolved the conflicts.
- That went well (happy with the performances and the rtcan driver).
- Idea was to stay as close as possible of the official Yocto branch
we are using. Does that make sense?
By reading your answer, I wondered if I did right. So I also tried to
compile the kernel from the ipipe-arm repo:
- Branch ipipe/5.4.y.
- That compiles and boots.
- But, for the rt_igb, same issue as previous procedure:
"Error 2 getting interrupt".
>> Note: to have the driver igb working with the Xenomai kernel, I can
>> use the legacy interrupts ("pci=nomsi" on the kernel command line).
>> Does this "error 2" sound familiar? Is there anything else I can try?
>
> ENOENT - you could try search the code for sources of this error code.
> But it may also come from the PCI or MSI core.
>
>>
>> I did not try with a standard x86-64 PC yet. Do you think it may still
>> help? I have the feeling that this irq issue is very specific to my
>> arm SOC.
>
> Not unlikely. I'm afraid there is no way around digging for the source of the
> error code. That can help to understand better what goes wrong
I tried so many different versions.
I finally came back to my initial version:
linux-fslc-imx 4.9.67
+ ipipe-core-4.9.51-arm-4.patch (adapted)
+ Xenomai 3.0.9 or 3.0.12.
- With this one, at least, the non-Xenomai igb driver works with the
I-pipe patch.
- I figured out that by disabling MSI (pci=nomsi), the irq counter in
/proc/xenomai/irq started to increment for rt_igb.
- Then, I confirmed that the buffers (ICMP or ARP frames) were correct
(printk in the igb_main.c source code).
- I also realized that the RX was working.
The RTnet stack was preparing an ARP response to my Windows ping.
- Only the TX was not good (garbage on Wireshark).
I finally have something working with the patch bellow.
So:
- pci=nomsi to have the irq counter incrementing.
- dma_sync_single_for_device in igb_tx_map to have rt_igb sending
good data.
My questions:
What are your feeling about that?
Is dma_sync real-time? Is it a good fix/workaround?
Why do I need to add such a dma_sync with my arm SoC?
- I suspect that this driver would work on a regular x86...
- Can you tell if it works on other arm SoC?
Any suggestion to do work the driver with MSI instead of legacy interrupts?
Any suggestion to do work rt_igb with Kernel 5.4 + Xenomai 3.2?
The patch (igb_tx_map with Xenomai 3.0.12):
--- kernel.ori/drivers/net/drivers/igb/igb_main.c
+++ kernel/drivers/net/drivers/igb/igb_main.c
@@ -4095,6 +4095,7 @@
size = skb->len;
dma = rtskb_data_dma_addr(skb, 0);
+ dma_sync_single_for_device(tx_ring->dev, dma, size, DMA_BIDIRECTIONAL);
Thank you,
Yann
