diff options
author | Alexander Kochetkov <al.kochet@gmail.com> | 2017-12-19 14:03:57 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2017-12-19 13:25:52 -0500 |
commit | 78aa09754d69ba19a55c59f490788ec1c85f41f0 (patch) | |
tree | 6f1bdac78231cd93f25e28a23f99d82aef40f4f5 /COPYING | |
parent | e688822d035b494071ecbadcccbd6f3325fb0f59 (diff) | |
download | linux-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 'COPYING')
0 files changed, 0 insertions, 0 deletions