[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171219.132623.806348776830008384.davem@davemloft.net>
Date: Tue, 19 Dec 2017 13:26:23 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: al.kochet@...il.com
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
f.fainelli@...il.com, edumazet@...gle.com
Subject: Re: [PATCH v2] net: arc_emac: restart stalled EMAC
From: Alexander Kochetkov <al.kochet@...il.com>
Date: Tue, 19 Dec 2017 14:03:57 +0300
> 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@...il.com>
Applied.
Powered by blists - more mailing lists