On 12/17/2021 5:30 AM, Martin Pecka wrote:
> Thanks for the very prompt reply, Jake. My answers below.
>> What version of the kernel and drivers are you using?
> Linux clone-robot-jetson 4.9.253-tegra #1 SMP PREEMPT Mon Jul 26
> 12:19:28 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux
>
> driver: igb
> version: 5.4.0-k
> firmware-version: 1.2.1
>
> driver: ixgbe
> version: 4.4.0-k
>
Ok. So its based on the 4.9 kernel?
At a glance, at least for ixgbe it looks like at least one potential
commit since 4.9 to ixgbe_ptp.c could be at fault:
aeb4c73100be ("ixgbe: Fix incorrect bitwise operations of PTP Rx
timestamp flags")
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeb4c73100be8aade8a1189b50bd226b709ca8bb
If you're comfortable checking source, you could see if your kernel has
this particular defect or not. At least this would help us confirm the
case for X540.
> Unfortunately, it'd be difficult to test newer kernels as this is NVidia
> Jetson Xavier AGX, which needs an nvidia-customized kernel to run. They
> haven't issued yet any newer versions. But if there is a known bug in
> the NIC drivers in this kernel version, I'd understand that there's not
> much to do (except e.g. asking NVidia to backport the patches).
>> So this is the X540 which is receiving the frames? The "SYNC without
>> timestamp" means that the packet is received without a timestamp.
> Yes, the problematic chips are X540 and 82576.
>> Could you check the ethtool stats output and see if rx_hwtstamp_cleared
>> is incrementing?
> No, it is always zero on all tested cards. Even on the working card with
> I350.
Ok, so its probably not the Rx timestamp hang problem where a timestamp
is stuck in the register but not freed up.
>> Another possible check would be to use the test utility testptp and
>> verify that the network device clock is actually incrementing.
> Ran the test, time is incrementing.
>> I believe "SYNC without timestamp" can occur if the reported timestamp is 0?
> Is that the same as not set?
>> Could you try layer 3 UDP packets instead of L2?
> No difference with either UDPv4 or UDPv6 transports. I also tried P2P
> instead of E2E, but still no difference.
>
Interesting. So its not related to the layer. That surprises me since
these devices don't support timestamping all frames. I had thought
possibly there was a bug in the L2 setup. But this seems to indicate the
issue is not in the packet layer setup...
> I attach two PCAPs from the client machine recorded using tshark.
> ptp_goog.pcapng is the case with I350 where PTP works. ptp_bad.pcapng is
> the case with 82576 where PTP does not work. I saw only one difference -
> logMessagePeriod is -3 in the bad case and 0 in the good case. But I
> couldn't find any documentation on what does this value mean.
>
I'm not familiar with what logMessagePeriod means either.
> I'll add one maybe relevant information - the computer I use as a client
> has an integrated PTP-capable NIC, too (eqos driver). With this one, PTP
> sync works. And both the non-working PCIe cards are two-port cards
> (without an internal switch - each port is connected as a separated PCI
> device). So in the end, the system sees 3 NICs and 3 PTP clock devices.
> When running ptp4l, I always specify just the NIC and let ptp4l select
> the clock.
>
Yea that's fine. ptp4l is able to figure out which clock is associated
with which NIC.
> Thanks for further help,
> Martin
>
The only other thing I might suggest is using ftrace to check whether
igb_ptp_rx_rgtstamp and related functions are actually being called.
This function is called in igb_process_skb_fields when a receive packet
is detected as having a timestamp captured in the register.
I believe ixgbe also has a similar function, but I am suspicious that
the ixgbe device is fixed with the commit mentioned above.
Thanks,
Jake
>
> _______________________________________________
> Linuxptp-users mailing list
> Linuxptp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
