AnsweredAssumed Answered

i.MX6 FEC stops generating receive interrupts

Question asked by Jaccon Bastiaansen on Apr 24, 2014
Latest reply on Nov 25, 2016 by Fabio Estevam

We are seeing strange ethernet behavior on the i.MX6.


In our networking setup, we connect a Linux PC and a SabreSD i.MX6 board using a switch (see the following picture)



| Ethernet  |
|switch   |


  |      |

  |      |

  |      |

+----------+    +-------------+

| Linux PC |    | i.MX6 board |

+----------+    +-------------+


Both network links are 1Gbit full duplex.


The SabreSD board runs mainline Linux 3.10.9 with the PREEMPT_RT patches + FEC driver from 3.14).
On Linux we have started the iperf server (network stress test tool) in UDP mode (command used: “iperf –s –u”).

The Linux PC runs Ubuntu 12. On this PC we:

  - ping the i.MX6 board every second

  - run the iperf client in UDP mode (command used: “while [ 1 ]; do iperf –c ‘IP address of SabreSD board’ -u -b 100m -t 30 -l 256;sleep 1;done”)


After a while (most of the time a couple of minutes), we see that the i.MX6 board stops replying to the pings from the Linux PC. Closer inspection shows that the FEC in the i.MX6 doesn’t generate receive frame interrupts anymore. The attached screenshots show that the RXF interrupt is enabled. We know that the FEC is still receiving Ethernet frames (because we see the event counters related to frame reception increasing), but no receive frame interrupts are being generated (only MII interrupts).


If you look in the RDAR register in the screenshots you see that it has the value 0 meaning that the FEC cannot write the received frame in main memory because of a lack of available free receive descriptors.


When we ping the Linux PC from the SabreSD board, we see the receive interrupts on the i.MX6 start occurring again. After studying the FEC driver we see that the driver also empties the receive buffer when handling a transmit interrupt. So it seems that the FEC starts generating receive interrupts again when free receive descriptors are available again.  Our question now is: how can the FEC get into state where it stops generating receive interrupts and how can we prevent this?