RE: rtnet rt_igb I210 not working with ARM
> > 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?
>
> In the best case, it's just a barrier (but there is already a wmb()). In the
> worst
> case, Linux code is triggered that actually does more, e.g.
> because DMA is not cache-coherent. You will have to analyze what is actually
> done in that function on your platform.
>
> > 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?
>
> I don't think this was tried on ARM so far, but then the topic will actually
> be
> rather SoC-specific.
Hi,
Maybe worth mentioning for those who face the same problem:
I did not go deeper with the DMA yet. I was happy with the tx performances.
But I faced a different issue with the rx, with 1 packets over 500 which was
lost at high frequency.
I got to do a similar patch (dma_sync) for the rx. See below (tx + rx). That
works for me and performances are validated.
--- a/kernel/drivers/net/drivers/igb/igb_main.c
+++ b/kernel/drivers/net/drivers/igb/igb_main.c
@@ -4143,6 +4143,7 @@ static void igb_tx_map(struct igb_ring *tx_ring,
* We also need this memory barrier to make certain all of the
* status bits have been updated before next_to_watch is written.
*/
+ dma_sync_single_for_device(tx_ring->dev, dma, size, DMA_TO_DEVICE);
wmb();
if (skb->xmit_stamp)
@@ -4764,13 +4765,19 @@ static struct rtskb *igb_fetch_rx_buffer(struct
igb_ring *rx_ring,
{
struct igb_rx_buffer *rx_buffer;
struct rtskb *skb;
+ dma_addr_t dma;
+ unsigned int size;
rx_buffer = _ring->rx_buffer_info[rx_ring->next_to_clean];
skb = rx_buffer->skb;
prefetchw(skb->data);
+ dma = rtskb_data_dma_addr(skb, 0);
+ size = le16_to_cpu(rx_desc->wb.upper.length);
+ dma_sync_single_for_cpu(rx_ring->dev, dma, size, DMA_FROM_DEVICE);
+
/* pull the header of the skb in */
- rtskb_put(skb, le16_to_cpu(rx_desc->wb.upper.length));
+ rtskb_put(skb, size);
rx_buffer->skb = NULL;
rx_buffer->dma = 0;
About previous patches to have multicast with RTnet
Hello Philippe, Jean-Baptiste, Jan, all, About https://xenomai.org/pipermail/xenomai/2019-March/040588.html [PATCH 00/16] multicast, VLAN support for RTnet and https://xenomai.org/pipermail/xenomai/2021-May/045164.html [PATCH 00/31] Update fec driver for xenomai 3 and linux kernel 5.4 and add I.MX8 support I am checking how to have multicast support with RTnet and I do not understand from which branch come the commits from Gilles + why they are not integrated to the master branch. I see that some commits were integrated (eb7f0dfd + ac17dceb + 04fab252) but that's not clear (I read CONTRIBUTING.md) why not all of them. Any plan to add the multicast support soon? >From where should I start if I want to give a try with the commits from the "multicast, VLAN support for RTnet" thread? Should I apply the patches from the mailing list? Thanks for your help, Yann
Re: dovetail-5.10: build-breakage on ARM
Jan Kiszka writes: > Hi Philippe, > > likely by accident: 5.10-dovetail-rebase lost disable_irq_if_pipelined / > enable_irq_if_pipelined macros. 5.16 was affected as well, 5.15 and 5.17 > are not. > > Jan Fixed upstream, thanks. -- Philippe.
Re: RTNET setup issue
On Thu, 2022-03-24 at 16:27 +0100, Paal Tamas wrote: > > I started the debug session using the rtifconfig.c file, since the > > rtifconfig command "fails fine". I added some trace to the > > rtifconfig.c (into the do_display() function) and rtnet_chrdev.c > > (into the rtnet_core_ioctl() function) files. In "all 64bit mode", > > when RTNET works as expected I see the followings in the user mode > > console and kernel trace: > > do_display enter > > do_display: IOC_RT_IFINFO=0xc0500082, sizeof(rtnet_core_cmd)=80 > > > > [ 36.616917] rtnet_core_ioctl: > > request=0xc0500082,sizeof(rtnet_core_cmd)=80 > > [ 36.616919] rtnet_core_ioctl: IOC_RT_IFINFO decoded > > > > This means the ioctl() call hit the target succesfully. > > > > When I compile the userland to 32bit the user mode trace is the > > following: > > > > do_display enter > > do_display: IOC_RT_IFINFO=0xc0500082, sizeof(rtnet_core_cmd)=80 > > do_display: ret=-1 > > ioctl: Inappropriate ioctl for device > > > > but nothing appears in the kernel trace. This means to me that the > > ioctl() call did not reach the rtnet_core_ioctl() funtion, rather > > failed somewhere in between the userspace and that kernel function > > call. > > > > I need some help here. I need to add more traces to the system, to > > find the place where the ioctl() call hits the wall. When the > > do_display() function of rtifconfig.c calls ioctl(), where can I > > find that certain ioctl() function? I am lost in the jungle of > > macros... Your mail client has a strange configuration / citation style. Took some time to realize that there is a question. Whenever you call ioctl() you end up in the Xenomai (libcobalt) wrapper. See lib/cobalt/rtdm.c (~ line 195). If do_ioctl (which triggers the Xenomai / RT syscall) fails, it will fall back to the Linux / NON-RT path. I guess that is where the "Inappropriate ioctl for device" is coming from. Linux simply doesn't know the requested call. I guess you have to figure out why the RT path fails. The interesting entry point inside the kernel should be in kernel/cobalt/posix/io.c (~line 63) calling rtdm_fd_ioctl() located in kernel/cobalt/rtdm/fd.c. rtdm_fd_ioctl() might bail out in some error conditions before triggering the trace infrastructure. That might be the reason why your trace did not mention any RT syscall. CONFIG_XENO_ARCH_SYS3264 is enabled on your end? HTH, Florian
dovetail-5.10: build-breakage on ARM
Hi Philippe, likely by accident: 5.10-dovetail-rebase lost disable_irq_if_pipelined / enable_irq_if_pipelined macros. 5.16 was affected as well, 5.15 and 5.17 are not. Jan -- Siemens AG, Technology Competence Center Embedded Linux
