On Wed, Nov 23, 2022 at 09:32:38PM +1100, David Mirabito wrote:
> In summary:
>
> Previously: if eth0 goes FAULTY, it may *never* recover if totally
> unrelated eth1 is flapping and producing a stream of useless RTNL messages.
> With this patch (or an equivalent): if eth0 goes faulty, the fault cl
Hi Miroslav,
Sure. Say we're running as a single-port ordinary clock: `ptp4l -i eth0`
and the system also has at least one other interface (eth1, ...) although
ptp4l is not configured to do anything with, or care about them.
When eth0 goes into a FAULTY state, a 16 second (by default) timeout is
On Tue, Nov 22, 2022 at 08:59:48PM -0800, davidjm via Linuxptp-devel wrote:
> Set the timer only when an event causes the port to transition to the
> FAULTY state. Previously this was done based only on the port's current
> state, and events on that port (such as RTNL messages) cause it to
> repeat
Set the timer only when an event causes the port to transition to the
FAULTY state. Previously this was done based only on the port's current
state, and events on that port (such as RTNL messages) cause it to
repeatedly re-arm itself, potentially never clearing.
Signed-off-by: davidjm
---
clock.
