This issue is having a severe impact at customer sites. Our DM8168-based products are installed at secure installations utilizing ethernet mac port security. The switch port shuts down if a packet with an unknown source mac address is transmitted. This is occurring fairly regularly at a number of sites with different systems in the middle of product use.
I created a private lan between two systems with a pc also connected running wireshark to be able to filter on any unknown mac. In a video call with udp packets there are multiple instances a day where the destination mac address in a packet is bad. The source mac is ok and other parts of the packets are ok. Sometimes other parts of the packets are bad like the lenght byte or wireshark detects an FCS error. More rare is the occurrence of the bad source mac. It might be days to a week apart, and in that case the whole packet looks bad, mostly zero’s, but some bytes not zero including the source and destination mac bytes. I can't detect a pattern with any of the bad data.
I added code to the davinci_emac driver in emac_dev_xmit right before the call to cpdma_chan_submit to test the first 12 bytes of data for the correct source and destination mac and it does not see a problem. I also tested the address after the xmit_complete and the data still looks ok.
This looks like a problem with cpdma or lower.
I also ran a test with iperf and tcp and see another problem. It looks like a bunch of bytes at the start of the packet get skipped and packet payload data is at the start where the source and dest mac should be.
This looks similar to these issues:
e2e.ti.com/.../389291
e2e.ti.com/.../388303
Our products have different ethernet configurations. One has a directly connected Realtek phy and the other has a direct GMII phyless connection to an embedded switch. The problem happens on both systems. Link speed and duplex do not matter. I think the related issues were seen on an evm. The kernel that we are using is in sync with current arago linux-omap kernel.
We have tuned tcp_rmem and tcp_wmem for our application. Using the defaults does not change the behavior.
cat /proc/sys/net/ipv4/tcp_wmem
4096 16384 1208320
cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 1208320