Error when using hardware timestamp in ptp

[shenfungping]

Error occured when ptp using hardware timestamp, does anyone met the same before and how it be fixed?

root@imx8mqevk:~# ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
root@imx8mqevk:~# sudo ptp4l -i eth0 -m -H
ptp4l[2861.116]: selected /dev/ptp0 as PTP clock
ptp4l[2861.117]: driver changed our HWTSTAMP options
ptp4l[2861.117]: tx_type 1 not 1
ptp4l[2861.117]: rx_filter 1 not 12
ptp4l[2861.118]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[2861.118]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[2861.118]: port 1: link up
ptp4l[2868.709]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2868.709]: selected best master clock e6b036.fffe.a0450a
ptp4l[2868.709]: assuming the grand master role
ptp4l[2869.711]: timed out while polling for tx timestamp
ptp4l[2869.711]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2869.711]: port 1: send sync failed
ptp4l[2869.711]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[2885.713]: driver changed our HWTSTAMP options
ptp4l[2885.713]: tx_type 1 not 1
ptp4l[2885.713]: rx_filter 1 not 12
ptp4l[2885.713]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[2893.506]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2893.506]: selected best master clock e6b036.fffe.a0450a
ptp4l[2893.506]: assuming the grand master role
ptp4l[2895.508]: timed out while polling for tx timestamp
ptp4l[2895.508]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2895.508]: port 1: send sync failed
ptp4l[2895.508]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)