When running ptp4l as a slave I face (every few second) get the following error:
ptp4l[556.407]: timed out while polling for tx timestamp
ptp4l[556.408]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
see please attached two photo log history of the problem -
If I do increase tx_timestamp_timeout, the error happens less frequently, but at 10 ms, ten times the default, it still happens frequently.
As I understand it, the tx timpestamp is returned by the SoC itself after sending the delay request message, so it is strange that it should take this much time. I don't whether the ptp4l author means that it is a driver bug when it takes much time, or when the timestamp does not arrive at all. I can see that the timestamp always arrive eventually when this happens by re-polling.
How come it takes so long time to get back the timestamp? Is this a bug? If not, how long should the timeout value be? how do I fix the problem to prevent that bug happen?
My kernel is based on linux centos ssh.