imx6 network issue

[will_intelli]

Hi,

I have a custom imx6 based board running linux 4.1.15 and am seeing an issue where if I leave the unit connected to our office network for a day or two, it eventually stops responding to pings.  In ethtool, when this happens I can see the IEEE_rx_macerr count start increasing, before the issue, the count is at 0.  IEEE_rx_frame_ok is also still increasing at this point.

root@imx6q-rotork-p2:~# ethtool -S eth0
NIC statistics:
     tx_dropped: 0
     tx_packets: 167
     tx_broadcast: 2
     tx_multicast: 8
     tx_crc_errors: 0
     tx_undersize: 0
     tx_oversize: 0
     tx_fragment: 0
     tx_jabber: 0
     tx_collision: 0
     tx_64byte: 9
     tx_65to127byte: 115
     tx_128to255byte: 35
     tx_256to511byte: 4
     tx_512to1023byte: 4
     tx_1024to2047byte: 0
     tx_GTE2048byte: 0
     tx_octets: 24236
     IEEE_tx_drop: 0
     IEEE_tx_frame_ok: 167
     IEEE_tx_1col: 0
     IEEE_tx_mcol: 0
     IEEE_tx_def: 0
     IEEE_tx_lcol: 0
     IEEE_tx_excol: 0
     IEEE_tx_macerr: 0
     IEEE_tx_cserr: 0
     IEEE_tx_sqe: 0
     IEEE_tx_fdxfc: 0
     IEEE_tx_octets_ok: 24236
     rx_packets: 26367
     rx_broadcast: 57490
     rx_multicast: 33103
     rx_crc_errors: 0
     rx_undersize: 0
     rx_oversize: 0
     rx_fragment: 0
     rx_jabber: 0
     rx_64byte: 63356
     rx_65to127byte: 65360
     rx_128to255byte: 24564
     rx_256to511byte: 59591
     rx_512to1023byte: 7342
     rx_1024to2047byte: 2762
     rx_GTE2048byte: 0
     rx_octets: 290435748
     IEEE_rx_drop: 0
     IEEE_rx_frame_ok: 26367
     IEEE_rx_crc: 0
     IEEE_rx_align: 0
     IEEE_rx_macerr: 63672
     IEEE_rx_fdxfc: 0
     IEEE_rx_octets_ok: 290435748

In ifconfig, the rx packet and rx byte counts stops altogether:

root@imx6q-rotork-p2:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 70:b3:d5:06:19:e8
          inet addr:10.1.254.22  Bcast:10.1.255.255  Mask:255.255.0.0
          inet6 addr: fe80::72b3:d5ff:fe06:19e8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1116380 errors:0 dropped:29330 overruns:0 frame:0
          TX packets:167 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:106022423 (101.1 MiB)  TX bytes:23418 (22.8 KiB)

Interrupts also stop:

root@imx6q-rotork-p2:~# cat /proc/interrupts | grep eth
281:     810435          0          0          0       GPC 118 Level     2188000.ethernet
282:          0          0          0          0       GPC 119 Level     2188000.ethernet

I can correct the problem by sending a single packet from the unit, eg:

ping 1.2.3.4

In this case 1.2.3.4 isn't a valid address, I'm using it to generate an ARP request.  It then continues to receive packets as expected, and the IEEE_rx_macerr stops incrementing.

Any ideas on what could be causing this?

Will.

[庞磊]

Hi ~

 did you solve this problem? I now run into the same problem with kernel 4.1.15.

[jimmychan]

may hit the errata of i.mx6q. please check the errata for ENET.

http://www.nxp.com/docs/en/errata/IMX6DQCE.pdf 

[marcomadrigal]

Hi,

I have a similar problem, I am using the g_ether driver to expose a network link over USB from my imx6. When the network load increases I stop receiving packets on my PC and the imx6 do not report any interrupts (even a ping from the imx6 to the pc stops working). If I send a ping from my computer to the imx6 then the connection restarts. If I stop the ping command from the PC then the connection hangs again. 

One interesting test I did was to stream a video over the USB link from the imx6 to the PC. It hangs faster in the way I increase the video size/ bitrate (i.e. the more data the faster it hangs). The interesting part is that if I send a ping command from the PC to the imx6 then the video resumes stopping with each ping. If I send more continuous data to the imx6 such as an iperf or another video then the video coming in from the imx6 is smooth. 

I have tested it with kernel 3.14.52 and 4.1.15 on Nitrogen6x, QWKS and a custom board, and all of them present the problem, however, similar kernel versions do not fail on another hardware which points to the fact that the mainline code (g_ether and network stack) is not the problem. Also, the fact that the issue seems to be the same no matter if the physical connection is USB or a dedicated ETH chip kind of takes the specific drivers out of the equation. 

Any help on this would be appreciated. 

Regards,