> -----Original Message-----
> From: Martin Pecka <pecka...@fel.cvut.cz>
> 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 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. 12. 21 v 13:13 linuxptp-users-requ...@lists.sourceforge.net
> napsal(a):
>
> > Ok. So its based on the 4.9 kernel?
> Yes.
> > 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.
>
> Fortunately, the kernel has ftrace already enabled, so I did the test
> with the PTP client running. What's interesting is that ftrace doesn't
> report any calls of igb_process_skb_fields. It does also report no
> usages of igb_ptp_rx_tgtstamp. However, I saw this in the log:
>
> kworker/4:0-9357 [004] ...1 471985.266393: igb_ptp_rx_hang
> <-igb_watchdog_task
> kworker/4:0-9357 [004] ...1 471985.266393: igb_rd32
> <-igb_ptp_rx_hang
>
> I'm not sure if it's helpful, but it's the only thing I got.
>
Ok. So those are expected to be called periodically. They are periodic
functions which check whether possible hang conditions are true.
The Rx hang detection is to check whether or not a Receive timestamp has been
marked as "valid" for longer than a few seconds. This implies that hardware
captured a receive timestamp but software never delivered the packet. If this
occurs, no future Rx timestamps would ever be triggered by hardware, because it
won't capture a new timestamp until the receive timestamp register valid bit is
cleared (If I recall correct, this is a Clear-on-Read event).
> Just to check, this is the way I'm reading the ftrace:
>
> echo function | sudo tee /sys/kernel/debug/tracing/current_tracer; for i
> in $(seq 1 10); do sudo cat /sys/kernel/debug/tracing/trace | grep -C3
> igb_ptp; done; echo nop | sudo tee /sys/kernel/debug/tracing/current_tracer
>
That seems a bit weird to me. You're writing function in, then reading, and
then disabling function tracer?
I would just do "echo function | sudo tee
/sys/kernel/debug/tracing/current_tracer" before the test starts, and then the
following:
cat /sys/kernel/debug/tracing/trace_pipe | grep -C3 ice_ptp
This command can be left executing (trace_pipe is a variant of the trace file
which acts as a pipe and will continue processing new traces until you close
the access, that way the cat stays open and reads it like a pipe instead of
getting an EOF).
You could then execute the test using ptp4l, and leave tracer as function the
whole time.
I suspect in your case what has happened is that the function tracer wasn't on
when the test was run since you only enabled it just before calling the cat
process to read it.
You can also limit the trace a bit by set_ftrace_filter, so if you jsut wanna
trace only igb calls you can do:
echo ':mod:igb' > /sys/kernel/debug/tracing/set_ftrace_filter
which will add filters for every function that is in the igb module and nothing
else. Then you shouldn't need the grep ice_ptp either.
Thanks,
Jake
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
