Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Tue, Apr 11, 2023 at 05:03:31AM +1000, Aris Theocharides via Linuxptp-users wrote: > > The card in question is a 4-port i210 PCIe - > https://www.lr-link.com/products/LRES3004PT.html That is a very strange looking card. I guess it has 4 i210 ASICs? What is under the giant heat sink? Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Tue, Apr 11, 2023 at 05:03:31AM +1000, Aris Theocharides via Linuxptp-users wrote: > > The card in question is a 4-port i210 PCIe - > https://www.lr-link.com/products/LRES3004PT.html > > It seems to behave for general use, but I can’t use it without PTP working. > > A single-port PCIe i210 behaves perfectly on the same mainboard, so I assume > that something interesting is happening in the i210 driver for this card. > > For interest, I have 2 of these cards, and both exhibit the same behaviour > (so, unlikely to be a failure of a specific card). A single-port i210 card > work perfectly. > > Not sure where from here. Maybe a full debug trace? Probably the generic work (see igb_ptp_tx_work()) is being delayed too much on your RT kernels. Try increasing tx_timestamp_timeout to a really large value, like 1000. Also try a non RT kernel. Proper fix is to let driver use ptp_aux_kworker/do_aux_work and set kernel thread to SCHED_FIFO at high priority. FWIW I have a box with three 1-port i210 PCIe cards that runs fine on vanilla kernel. HTH, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Layer 2 ptp on Nvidia Orin
On Mon, Apr 10, 2023 at 07:09:23PM +, Greiner, Andreas wrote: > We are using these versions: > > ptp4l: 3.1-00224-gd4adf87 > kernel: 5.10.104-tegra > > Are there any mistakes on our side? What else can we try? This is likely a bug in the vendor kernel. You should ask them to fix it for you. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] Layer 2 ptp on Nvidia Orin
Hello, we are currently trying to use ptp4l on a NVIDIA Orin to sync with a couple of sensors using layer 2 ptp. However, we get an error when starting the master instance on the Orin. uam@hubble:~$ sudo ptp4l -i eth0 -m -2 -l 7 ptp4l[922.980]: selected /dev/ptp0 as PTP clock ptp4l[923.053]: driver rejected most general HWTSTAMP filter ptp4l[923.059]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range ptp4l[923.120]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[923.121]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[923.121]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE As far as I can tell it should be supported by the hardware though, as this output of ethtool suggests: uam@hubble:~$ 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) one-step-sync (HWTSTAMP_TX_ONESTEP_SYNC) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) We are using these versions: ptp4l: 3.1-00224-gd4adf87 kernel: 5.10.104-tegra Are there any mistakes on our side? What else can we try? Kind regards, Andreas ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
The card in question is a 4-port i210 PCIe - https://www.lr-link.com/products/LRES3004PT.html It seems to behave for general use, but I can’t use it without PTP working. A single-port PCIe i210 behaves perfectly on the same mainboard, so I assume that something interesting is happening in the i210 driver for this card. For interest, I have 2 of these cards, and both exhibit the same behaviour (so, unlikely to be a failure of a specific card). A single-port i210 card work perfectly. Not sure where from here. Maybe a full debug trace? Aris > On 10 Apr 2023, at 11:09 pm, Richard Cochran wrote: > > On Mon, Apr 10, 2023 at 10:31:05PM +1000, Aris Theocharides via > Linuxptp-users wrote: > [snip] >> Debian 12 Kernel Module (based on Linux 6.1.20 kernel, modified by Debian): >> >>> filename: >>> /lib/modules/6.1.20-rt8/kernel/drivers/net/ethernet/intel/igb/igb.ko > > Hm, Debian is shipping a PREEMPT_RT kernel? That is news to me. Yes, albeit not the default, a (signed) RT variant is available from the official repos. >> root@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H >> ptp4l[11754.773]: selected /dev/ptp0 as PTP clock >> ptp4l[11754.818]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE >> ptp4l[11754.818]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on >> INIT_COMPLETE >> ptp4l[11754.819]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on >> INIT_COMPLETE >> ptp4l[11760.857]: port 1 (enp3s0): LISTENING to MASTER on >> ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES >> ptp4l[11760.857]: selected local clock 6cb311.fffe.663910 as best master >> ptp4l[11760.857]: port 1 (enp3s0): assuming the grand master role >> ptp4l[11761.868]: timed out while polling for tx timestamp >> ptp4l[11761.868]: increasing tx_timestamp_timeout may correct this issue, >> but it is likely caused by a driver bug > > Did you try this? ^^^ Yes, I tried increasing tx_timestamp_timeout - the reported issue persists. > [snip] ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] ptp4l passive phc synchronization with active phc in linux bonding
Hello experts, I need to configure PTP with linux bonding. I can see it is supported in active-passive configuration. I have following queries related to functioning of PTP with active-passive bonding: - Will passive/standby slave PHC synchronize itself with active slave PHC when active-passive NIC ports are on different PHCs? - Does the passive NIC port's PHC is ready to take-over when the current active slave NIC goes down or does this require the passive NIC's PHC to synchronize first? Thanks and regards Shashank Varshney ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
Re: [Linuxptp-users] Intel i210 PTP HW timestamping not supported
On Mon, Apr 10, 2023 at 10:31:05PM +1000, Aris Theocharides via Linuxptp-users wrote: > Intel Module (from SF, v 5.13.16): Can't comment on that, since not mainline linux. > Debian 12 Kernel Module (based on Linux 6.1.20 kernel, modified by Debian): > > > filename: > > /lib/modules/6.1.20-rt8/kernel/drivers/net/ethernet/intel/igb/igb.ko Hm, Debian is shipping a PREEMPT_RT kernel? That is news to me. > root@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H > ptp4l[11754.773]: selected /dev/ptp0 as PTP clock > ptp4l[11754.818]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[11754.818]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[11754.819]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[11760.857]: port 1 (enp3s0): LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[11760.857]: selected local clock 6cb311.fffe.663910 as best master > ptp4l[11760.857]: port 1 (enp3s0): assuming the grand master role > ptp4l[11761.868]: timed out while polling for tx timestamp > ptp4l[11761.868]: increasing tx_timestamp_timeout may correct this issue, but > it is likely caused by a driver bug Did you try this? ^^^ > AVNU Module (from AVNU): > > > filename: > > /lib/modules/6.1.20-rt8/kernel/drivers/net/igb_avb/igb_avb.ko > > version:5.3.2_AVB Can't comment on that, since not mainline linux. IMHO avnu driver stuff is of dubious quality. Thanks, Richard ___ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
[Linuxptp-users] Intel i210 PTP HW timestamping not supported
I’m trying to get an I210 card working with LinuxPTP. The command I use works fine on another interface: Debian 12 Kernel Module (I225 interface, eno2): > ^Croot@controller:~/proj/igb_avb/kmod# ptp4l -i eno2 -m -2 -H > ptp4l[12580.495]: selected /dev/ptp4 as PTP clock > ptp4l[12580.570]: port 1 (eno2): INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[12580.570]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[12580.570]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[12588.253]: port 1 (eno2): LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[12588.253]: selected local clock 3cecef.fffe.7b900b as best master > ptp4l[12588.253]: port 1 (eno2): assuming the grand master role But for any of the range of I210 driver’s I’ve tried, I can’t get it to work. Intel Module (from SF, v 5.13.16): > filename: > /lib/modules/6.1.20-rt8/updates/drivers/net/ethernet/intel/igb/igb.ko > version:5.13.16 ^Croot@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H ptp4l[8769.060]: selected /dev/ptp0 as PTP clock ptp4l[8769.110]: driver rejected most general HWTSTAMP filter ptp4l[8769.110]: ioctl SIOCSHWTSTAMP failed: Operation not supported ptp4l[8769.158]: port 1 (enp3s0): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[8769.158]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[8769.158]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE Debian 12 Kernel Module (based on Linux 6.1.20 kernel, modified by Debian): > filename: > /lib/modules/6.1.20-rt8/kernel/drivers/net/ethernet/intel/igb/igb.ko root@controller:~/proj/igb-5.13.16/src# ptp4l -i enp3s0 -m -2 -H ptp4l[11754.773]: selected /dev/ptp0 as PTP clock ptp4l[11754.818]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[11754.818]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[11754.819]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[11760.857]: port 1 (enp3s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[11760.857]: selected local clock 6cb311.fffe.663910 as best master ptp4l[11760.857]: port 1 (enp3s0): assuming the grand master role ptp4l[11761.868]: timed out while polling for tx timestamp ptp4l[11761.868]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[11761.868]: port 1 (enp3s0): send sync failed ptp4l[11761.868]: port 1 (enp3s0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) Linux 6.1 Kernel Module (string from 6.1 Linux Kernel tag): > filename: /lib/modules/6.1.20-rt8/updates/igb.ko root@controller:~/proj/linux-6.1/drivers/net/ethernet/intel/igb# ptp4l -i enp3s0 -m -2 -H ptp4l[12277.722]: selected /dev/ptp0 as PTP clock ptp4l[12277.794]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[12277.794]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[12277.795]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[12284.253]: port 1 (enp3s0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[12284.253]: selected local clock 6cb311.fffe.663910 as best master ptp4l[12284.253]: port 1 (enp3s0): assuming the grand master role ptp4l[12285.264]: timed out while polling for tx timestamp ptp4l[12285.264]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug ptp4l[12285.264]: port 1 (enp3s0): send sync failed ptp4l[12285.264]: port 1 (enp3s0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) AVNU Module (from AVNU): > filename: /lib/modules/6.1.20-rt8/kernel/drivers/net/igb_avb/igb_avb.ko > version:5.3.2_AVB > root@controller:~/proj/igb_avb/kmod# ptp4l -i enp3s0 -m -2 -H > ptp4l[12490.551]: selected /dev/ptp0 as PTP clock > ptp4l[12490.614]: port 1 (enp3s0): INITIALIZING to LISTENING on INIT_COMPLETE > ptp4l[12490.614]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[12490.614]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on > INIT_COMPLETE > ptp4l[12497.419]: port 1 (enp3s0): LISTENING to MASTER on > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > ptp4l[12497.419]: selected local clock 6cb311.fffe.663910 as best master > ptp4l[12497.419]: port 1 (enp3s0): assuming the grand master role > ptp4l[12498.429]: timed out while polling for tx timestamp > ptp4l[12498.430]: increasing tx_timestamp_timeout may correct this issue, but > it is likely caused by a driver bug > ptp4l[12498.430]: port 1 (enp3s0): send sync failed > ptp4l[12498.430]: port 1 (enp3s0): MASTER to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) There are also a number of other issues with the Intel i210 card. "Detected Tx Unit Hang", "exceed max 2 second” for example. I’m a bit stuck - any hints from anyone who has it working? Aris ___
