When ptp4l detects a fault, the application stops for a short time until
the fault_reset_interval has passed.

Since commit 3b82f227ce96 ("clock: Monitor the link status using a RT
netlink socket."), the clock state machine will not try to restart a port
when link is down. This makes sense because a port without link will
obviously just immediately fault again.

However, if a user configures fault_reset_interval with ASAP this behavior
differs. The ASAP value is a special keyword to request clearing the fault
as soon as possible. In this case, the fault is cleared in port.c
immediately as its detected.

Doing so ignores the link status, and thus restarts even when link is down.
This leads to further timeouts and faults. Rather than let these faults
happen just follow the same behavior pattern as the timer-based fault
clearing. Don't clear the fault when link is down, instead wait until link
is restored.

Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com>
---
I brought this up about a year ago at [1], but Richard seemed to think the
ASAP behavior was expected.

I've had several users get confused and complain when they use ASAP and then
see timeouts.

I believe we should have the same behavior for both ASAP and timed restarts,
as it really doesn't make sense to clear the fault when we know that we'll
just fault again immediately.

 port.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/port.c b/port.c
index 871ad6818c20..756ff3a7b877 100644
--- a/port.c
+++ b/port.c
@@ -3412,7 +3412,7 @@ int port_state_update(struct port *p, enum fsm_event 
event, int mdiff)
        if (PS_FAULTY == next) {
                struct fault_interval i;
                fault_interval(p, last_fault_type(p), &i);
-               if (clear_fault_asap(&i)) {
+               if (port_link_status_get(p) && clear_fault_asap(&i)) {
                        pr_notice("%s: clearing fault immediately", 
p->log_name);
                        next = p->state_machine(next, EV_FAULT_CLEARED, 0);
                }
-- 
2.37.1.394.gc50926e1f488



_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Reply via email to