bug ERR6358 in VF500 or iMX6 makes Ethernet send slow

NXP decribes in VYBRID_2N02G.pdf a bug in the ethernet controller of the processors imx6 and VF500. This bug in the errata sheet is ERR6358.
The effect is, that some of the ethernetpackets will not be send, or send with a big delay. In fact it is never the first packet, of a bunch of packets, that will be delayed.
In our case, the delay could be 4 seconds or more.
Newer versions of the ethernet driver fec.c have a correction for that problem.
I
This is the patch

Index: drivers/net/fec.c
===================================================================
--- drivers/net/fec.c (revision 94)
+++ drivers/net/fec.c (working copy)
@@ -469,7 +469,12 @@
if (netif_queue_stopped(ndev))
netif_wake_queue(ndev);
}
- }
+ }
+
+ /* ERR006358: Keep the transmitter going */
+ if (bdp != fep->cur_tx && readl(fep->hwp + FEC_X_DES_ACTIVE) == 0)
+ writel(0, fep->hwp + FEC_X_DES_ACTIVE);
+
fep->dirty_tx = bdp;
spin_unlock(&fep->hw_lock);
}

For me, the patch solves the problem.

The recent version linux-3.0.15-fsvybrid-V2.2 does not contain this patch. So I think it is a good idea to give this patch to all users of VF500-processors.
By the way.
All of the iMx6 have the same problem.
And some of the iMX6-derivates have some additional problems.

The software, that runs on the picocomA5 is an echoserver. That means it reads on port 7 udp and resends the data. The other side generates some well known data, sends this data to the picocomA5 and verifies the content. If successfull it prints out the time difference between sending and receiving. This is done in a loop from 10 to 65000 with an increment step of 16. That means the first udp packet has the size 10, the next one 26, etc. The bug ERR6358 could be observed 1 to 10 times for one complete loop. First failures might be around lengths of 2000 to 3000 Bytes. It is very important that there is absolutely no other ethernet traffic on picocoma5. However a tcpdump to a file is allowed. However in the tcpdump on picoA5 you would see, that the netdriver pretends, that it has sent the data. Only the tcpdump on the other side would show the reality. Our test system is an ubuntu system. We detected that in case of the error, the ubuntu send an unicast arp after 4 seconds of silence. This arp packet made the picocom to generate an answer, and then there was a flow of data again.