[Linuxptp-devel] recvmsg tx timestamp failed: Resource temporarily unavailable

[Roskam, Gert-Jan]

We are using the igb network driver on a linux system with a 82576
network chip.
The system works good with ptp4l, but if there is data activity on the
ethernet connection sometimes
ptp4l will log:

Mar 21 18:07:41 OpenWrt user.err ptp4l: [1534.888] recvmsg tx timestamp
failed: Resource temporarily unavailable
Mar 21 18:07:41 OpenWrt user.err ptp4l: [1534.889] port 1: send delay
request failed
Mar 21 18:07:41 OpenWrt user.notice ptp4l: [1534.889] port 1: SLAVE to
FAULTY on FAULT_DETECTED

And will start to resync again sometime later.

Mar 21 18:07:57 OpenWrt user.notice ptp4l: [1550.909] port 1: FAULTY to
LISTENING on FAULT_CLEARED
Mar 21 18:07:58 OpenWrt user.notice ptp4l: [1551.790] port 1: new
foreign master 00a069.fffe.0b4969-1

This will happen quite regularly.

I have looked this up in the driver and it seems that recvmsg is
returning EAGAIN constantly. (It is retrying 100 times)

This behavior makes ptp unusable on our system.
Is anyone aware of this problem or has a pointer to a solution?

Thanks,
Gert-Jan




HBM Netherlands B.V., Schutweg 15a, NL-5145 NP Waalwijk, The Netherlands | www.hbm.com

Registered as B.V. (Dutch limited liability company) in the Dutch commercial register 08183075 0000
Company domiciled in Waalwijk | Managing Directors : Ben Keetman, Peter Ackermans

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

________________________________

Gert-Jan Roskam
Embedded Software Engineer


E-Mail: gert-***@hbm.com <mailto:gert-***@hbm.com>





________________________________

[Keller, Jacob E]

Hello Gert-Jan -

This is a known problem with the 82576 network chip. It simply can't return the hardware timestamp from the Tx packet fast enough for the 100 loops. The current known work around for this hardware is to increase the retry count from 100 to something higher. There is nothing the driver can do to obtain the packet timestamp faster than it already does.

If you increase the "tx_timestamp_retries" to a higher value, say maybe 2000 it should resolve the issue generally. It is possible that a timestamp is simply dropped but that shouldn't happen too often.

Thanks


- Jake

From: Roskam, Gert-Jan [mailto:Gert-***@hbm.com]
Sent: Thursday, March 21, 2013 1:22 PM
To: linuxptp-***@lists.sourceforge.net
Subject: [Linuxptp-devel] recvmsg tx timestamp failed: Resource temporarily unavailable

We are using the igb network driver on a linux system with a 82576 network chip.
The system works good with ptp4l, but if there is data activity on the ethernet connection sometimes
ptp4l will log:

Mar 21 18:07:41 OpenWrt user.err ptp4l: [1534.888] recvmsg tx timestamp failed: Resource temporarily unavailable
Mar 21 18:07:41 OpenWrt user.err ptp4l: [1534.889] port 1: send delay request failed
Mar 21 18:07:41 OpenWrt user.notice ptp4l: [1534.889] port 1: SLAVE to FAULTY on FAULT_DETECTED

And will start to resync again sometime later.

Mar 21 18:07:57 OpenWrt user.notice ptp4l: [1550.909] port 1: FAULTY to LISTENING on FAULT_CLEARED
Mar 21 18:07:58 OpenWrt user.notice ptp4l: [1551.790] port 1: new foreign master 00a069.fffe.0b4969-1

This will happen quite regularly.

I have looked this up in the driver and it seems that recvmsg is returning EAGAIN constantly. (It is retrying 100 times)

This behavior makes ptp unusable on our system.
Is anyone aware of this problem or has a pointer to a solution?

Thanks,
Gert-Jan

[Keller, Jacob E]

Also, quick question, what version of the driver/kernel are you using for igb? It is possible some fixes that would help reduce the error are in a newer kernel/driver.

Thanks


- Jake

From: Keller, Jacob E [mailto:***@intel.com]
Sent: Thursday, March 21, 2013 1:39 PM
To: Roskam, Gert-Jan; linuxptp-***@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] recvmsg tx timestamp failed: Resource temporarily unavailable

Hello Gert-Jan -

This is a known problem with the 82576 network chip. It simply can't return the hardware timestamp from the Tx packet fast enough for the 100 loops. The current known work around for this hardware is to increase the retry count from 100 to something higher. There is nothing the driver can do to obtain the packet timestamp faster than it already does.

If you increase the "tx_timestamp_retries" to a higher value, say maybe 2000 it should resolve the issue generally. It is possible that a timestamp is simply dropped but that shouldn't happen too often.

Thanks


- Jake

From: Roskam, Gert-Jan [mailto:Gert-***@hbm.com]
Sent: Thursday, March 21, 2013 1:22 PM
To: linuxptp-***@lists.sourceforge.net<mailto:linuxptp-***@lists.sourceforge.net>
Subject: [Linuxptp-devel] recvmsg tx timestamp failed: Resource temporarily unavailable

We are using the igb network driver on a linux system with a 82576 network chip.
The system works good with ptp4l, but if there is data activity on the ethernet connection sometimes
ptp4l will log:

Mar 21 18:07:41 OpenWrt user.err ptp4l: [1534.888] recvmsg tx timestamp failed: Resource temporarily unavailable
Mar 21 18:07:41 OpenWrt user.err ptp4l: [1534.889] port 1: send delay request failed
Mar 21 18:07:41 OpenWrt user.notice ptp4l: [1534.889] port 1: SLAVE to FAULTY on FAULT_DETECTED

And will start to resync again sometime later.

Mar 21 18:07:57 OpenWrt user.notice ptp4l: [1550.909] port 1: FAULTY to LISTENING on FAULT_CLEARED
Mar 21 18:07:58 OpenWrt user.notice ptp4l: [1551.790] port 1: new foreign master 00a069.fffe.0b4969-1

This will happen quite regularly.

I have looked this up in the driver and it seems that recvmsg is returning EAGAIN constantly. (It is retrying 100 times)

This behavior makes ptp unusable on our system.
Is anyone aware of this problem or has a pointer to a solution?

Thanks,
Gert-Jan