Customer using EZSDK 5_04_00_11
The problem they have is that CPU does not receive an interrupt of reception of Ethernet packet on EMAC0 port.
During it, CPU can send a packet through EMAC0. The problem is only on receive direction.
We don’t know about EMAC1 because the production does not use it.
They checked register of EMAC0 and ARM Interrupt Controller module.
There is no difference between in bad condition and in good condition.
During the problem, the “ifconfig” shows something like below:
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0D:2E:00:00:20
inet addr:172.17.0.32 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:664765 errors:0 dropped:77 overruns:2883662 frame:2883681
TX packets:193008 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:687965140 (656.0 MiB) TX bytes:17466853 (16.6 MiB)
Interrupt:40 Base address:0x8000
The number of RX packets never changes. The number of overruns increments every time.
And the data below is a dump of hardware statics registers. The RXSOFOVERRUNS(offset 284h) and the RXDMAOVERRUNS (offset 28Ch) is not 0.
ADDR 0x4a100200 0x003BA1FC 0x00014676 0x0000079C 0x00000000
ADDR 0x4a100210 0x00000000 0x00000000 0x00000000 0x00000000
ADDR 0x4a100220 0x00000000 0x00000000 0x00014B12 0x00000000
ADDR 0x4a100230 0xDA0F6BAF 0x00033E94 0x0002270A 0x00001DDC
ADDR 0x4a100240 0x00000000 0x00000000 0x00000000 0x00000000
ADDR 0x4a100250 0x00000000 0x00000000 0x00000000 0x00000000
ADDR 0x4a100260 0x00000000 0x012B3594 0x0005A28D 0x000A3B18
ADDR 0x4a100270 0x00059515 0x00017AD1 0x0001ED74 0x00260803
ADDR 0x4a100280 0xE0DC2B64 0x000001E0 0x00000000 0x000001F8
This issue can occur under heavy network traffic. There are variety of unicast, multicast, and broadcast on the network.
When there is a network loop, it looks it can increase a probability to cause this problem.
On the other hand, when they tried to reproduce this problem on test bench with simulator, they were able to cause “overruns counter”, but the EMAC0 never got stuck. It was able to communicate after removing heavy load.
Please advise an idea to investigate this issue.
Currently, there are 2 ways to recover the condition.
(1) Software (Linux) reboot
(2) Turn down the eth0 and up
(i.e) ifconfig eth0 down, then, ifconfig eth0 up.
