summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorAlexander Kochetkov <al.kochet@gmail.com>2017-12-19 14:03:57 +0300
committerDavid S. Miller <davem@davemloft.net>2017-12-19 13:25:52 -0500
commit78aa09754d69ba19a55c59f490788ec1c85f41f0 (patch)
tree6f1bdac78231cd93f25e28a23f99d82aef40f4f5 /Documentation
parente688822d035b494071ecbadcccbd6f3325fb0f59 (diff)
downloadlinux-78aa09754d69ba19a55c59f490788ec1c85f41f0.tar.bz2
net: arc_emac: restart stalled EMAC
Under certain conditions EMAC stop reception of incoming packets and continuously increment R_MISS register instead of saving data into provided buffer. The commit implement workaround for such situation. Then the stall detected EMAC will be restarted. On device the stall looks like the device lost it's dynamic IP address. ifconfig shows that interface error counter rapidly increments. At the same time on the DHCP server we can see continues DHCP-requests from device. In real network stalls happen really rarely. To make them frequent the broadcast storm[1] should be simulated. For simulation it is necessary to make following connections: 1. connect radxarock to 1st port of switch 2. connect some PC to 2nd port of switch 3. connect two other free ports together using standard ethernet cable, in order to make a switching loop. After that, is necessary to make a broadcast storm. For example, running on PC 'ping' to some IP address triggers ARP-request storm. After some time (~10sec), EMAC on rk3188 will stall. Observed and tested on rk3188 radxarock. [1] https://en.wikipedia.org/wiki/Broadcast_radiation Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions