You said this is an Nvidia vendor kernel on the jetson?
I would try a mainline kernel without their hacks.
I've already tried that with this card in a normal x86 Ubuntu computer
with kernels 5.4 and 5.15. The behavior was exactly the same, though.
Martin
smime.p7s
Description: Elektronicky
On Wed, Jan 12, 2022 at 03:12:15PM +0100, Martin Pecka wrote:
> So from the setup point of view, everything seems correct to me.
Yes sounds like it.
You said this is an Nvidia vendor kernel on the jetson?
I would try a mainline kernel without their hacks.
Thanks,
Richard
_
So it seems the card timestamps FOLLOW_UP and DELAY_RESP packets, but does
not timestamp SYNC packets. Why could this be? Can it somehow mismatch SYNC
and FOLLOW_UP messages in the chip and stamp the wrong one? (I think
FOLLOW_UP stamps are not good for anything, are they?). Or is it still some
pr
On Tue, Jan 11, 2022 at 04:57:25PM +0100, Martin Pecka wrote:
> So it seems the card timestamps FOLLOW_UP and DELAY_RESP packets, but does
> not timestamp SYNC packets. Why could this be? Can it somehow mismatch SYNC
> and FOLLOW_UP messages in the chip and stamp the wrong one? (I think
> FOLLOW_U
I did a deeper investigation of the "received SYNC without timestamp"
problem on the Intel 82576 card.
I instrumented port.c like this:
if (msg_sots_missing(msg) &&
!(p->timestamping == TS_P2P1STEP && msg_type(msg) == PDELAY_REQ)) {
pr_err("%s: received %s without timestamp"
Okay, I got the Linux 5.11 version compiling on the 4.9 kernel (5.15
version was too new).
This is what I get (not sure if I'm running it correctly):
$ sudo ./timestamp eth2 SOF_TIMESTAMPING_RX_HARDWARE PTPV2
SOF_TIMESTAMPING_TX_HARDWARE IP_MULTICAST_LOOP
SOF_TIMESTAMPING_RAW_HARDWARE SO_TIME
On Thu, Jan 06, 2022 at 05:24:48PM +0100, Martin Pecka wrote:
> Is there any other way to test the timestamping? E.g. a short C snippet to
> compile and figure out if the stamps are coming if requested?
In the linux kernel source tree:
tools/testing/selftests/net/timestamping.c
HTH,
Ric
Dne 31. 12. 21 v 1:41 Keller, Jacob E napsal(a):
You won't see igb_process_skb_fields in the grep for ptp, because it
doesn't have ptp in its name, nor does its caller.
Did not mention it, but of course I searched for it with a different
grep pattern. There were none, though! Could there be anot
On 12/29/2021 1:12 PM, pecka...@fel.cvut.cz wrote:
> Thanks for the ftrace tips, Jake.
>
> I ran it with a 'igb_*' filter and grepped everything with ptp and
> excluded the rx_hang calls. This is the whole trace after starting the
> PTP client:
>
> ptp4l-23256 [007] ...1 1064642.422359
Thanks for the ftrace tips, Jake.
I ran it with a 'igb_*' filter and grepped everything with ptp and
excluded the rx_hang calls. This is the whole trace after starting the
PTP client:
ptp4l-23256 [007] ...1 1064642.422359: igb_ptp_gettime_82576
<-ptp_clock_gettime
ptp4l
> -Original Message-
> From: Martin Pecka
> Sent: Wednesday, December 22, 2021 4:16 PM
> To: linuxptp-users@lists.sourceforge.net
> Subject: Re: [Linuxptp-users] received SYNC without timestamp
>
> Hi Jake and others.
>
> I'm sorry for the slow respon
Hi Jake and others.
I'm sorry for the slow response time, but it's Christmas time and I have
vacation. This also means I won't physically get to the computer until
January, but it is still running with the faulty Gbit card (igb driver),
so I can examine it remotely. Answers follow.
Dne 18. 1
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
>
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: ixg
On 12/16/2021 9:04 AM, Martin Pecka wrote:
> Hi PTP users.
>
> We bought a few PCIe network cards for testing, all with Intel chipsets
> and supposedly supporting PTP. I succeeded running HW-stamping PTP L2
> client on a card with I350 chipset and igb driver.
>
> However, two of the cards have
Hi PTP users.
We bought a few PCIe network cards for testing, all with Intel chipsets
and supposedly supporting PTP. I succeeded running HW-stamping PTP L2
client on a card with I350 chipset and igb driver.
However, two of the cards have a problem. The symptoms are the same,
although one is
16 matches
Mail list logo
