Re: [Linuxptp-users] DSA bridge PTP issues

[Riccardo L. <la...@le...>]

Il 28/03/23 17:50, Vladimir Oltean ha scritto:
> ah, ok, I didn't notice it :)
>
> so with PTP over IP, you'll also need these kernel config options and
> commands for the software bridge to leave PTP traffic on the bridge
> ports (so ptp4l can process it), and not "steal" it.
>
> CONFIG_BRIDGE_NF_EBTABLES=y
> CONFIG_BRIDGE_EBT_BROUTE=y
> CONFIG_BRIDGE_EBT_T_FILTER=y
> CONFIG_BRIDGE_EBT_IP=y
> CONFIG_BRIDGE_EBT_IP6=y
>
> /sbin/ebtables --table broute --append BROUTING --protocol 0x88F7 --jump DROP
>
> /sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol udp --ip-destination-port 320 --jump DROP
> /sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol udp --ip-destination-port 319 --jump DROP
>
> /sbin/ebtables --table broute --append BROUTING --protocol 0x86DD --ip6-protocol udp --ip6-destination-port 320 --jump DROP
> /sbin/ebtables --table broute --append BROUTING --protocol 0x86DD --ip6-protocol udp --ip6-destination-port 319 --jump DROP

Those kernel options were unselected. I've recompiled the kernel. Still not working.

ebtables dump:
	root@imx8mp-leaff-evk:~# ebtables --table broute --list
	Bridge table: broute
	
	Bridge chain: BROUTING, entries: 5, policy: ACCEPT
	-p PTP -j DROP
	-p IPv4 --ip-proto udp --ip-dport 320 -j DROP
	-p IPv4 --ip-proto udp --ip-dport 319 -j DROP
	-p IPv6 --ip6-proto udp --ip6-dport 320 -j DROP
	-p IPv6 --ip6-proto udp --ip6-dport 319 -j DROP

Now my ptp network is made up of two nodes:
A = reference board (standard lan hardware configuration, no dsa)
B = our development board (Marvell DSA)

On A I'm running ptp4l on IPv4 transport and highest priority (so, always grand master).

On B, ptp4l with standard priority don't see any master on the network and promotes itself as gm.
On A I see there is a new master, but A remains gm due to higher priority.

A log:
	root@imx8mp-var-dart:~# ptp4l -i eth0 --tx_timestamp_timeout=40 -m -4 --priority1=0 -P
	ptp4l[4320.662]: selected /dev/ptp1 as PTP clock
	ptp4l[4320.664]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[4320.664]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[4327.580]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
	ptp4l[4327.580]: selected local clock f8dc7a.fffe.739f22 as best master
	ptp4l[4327.581]: port 1: assuming the grand master role
	ptp4l[4365.680]: port 1: new foreign master de5c00.fffe.941eb2-1
	ptp4l[4369.682]: selected best master clock de5c00.fffe.941eb2
	ptp4l[4369.682]: port 1: assuming the grand master role

B log: (here you see i passed two lan ports to force boundary clock mode, don't know if this is relevant. Anyway, there was ptp traffic on lan2 only)
	root@imx8mp-leaff-evk:~# ptp4l -H -mq --tx_timestamp_timeout=40 -i lan2 -i lan3 -4 -P
	ptp4l[245.645]: selected /dev/ptp0 as PTP clock
	ptp4l[245.648]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[245.650]: port 2: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[245.650]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
	ptp4l[252.318]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
	ptp4l[252.318]: selected local clock de5c00.fffe.941eb2 as best master
	ptp4l[252.318]: port 1: assuming the grand master role
	ptp4l[252.954]: port 2: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
	ptp4l[252.954]: selected local clock de5c00.fffe.941eb2 as best master
	ptp4l[252.954]: port 1: assuming the grand master role
	ptp4l[252.954]: port 2: assuming the grand master role

It looks like outgoing ptp packets get routed fine while incoming ones get ignored/filtered/sucked-into-void
Is there any downsides using -2 instead the default IPv4 transport?

By the way sometimes I had some "port [n]: received SYNC without timestamp" messages when using -2 that went away
when I added the broute on EtherType 0x88F7.

> | ptp4l[2095.455]: master offset      17973 s2 freq +1000000 path delay       369
>
> This "freq +1000000" is odd. Who plays the role of the PTP master?
> Its clock is running way too fast, the switch can't keep up with it.
> If it's linuxptp-based, you can reset its frequency with
> "phc_ctl /dev/ptp0 freq 0" and that should get things back to normal
> (unless the PHC of the master is under the control of another process
> which is persistently causing this).

Master was the reference board that was a slave in previous experiments.
A power cycle fixed the issue, probably was the clock speed, as you said.

> | ptp4l[1857.988]: timed out while polling for tx timestamp
> | ptp4l[1857.988]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
>
> Here, there may simply be too much MDIO traffic, and 40 ms is not enough
> to collect timestamps. Can you try increasing it more (100 ms)?
>
> What MDIO controller is this? The one from the FEC? If so, does your
> kernel have this patch (and related)?
> [...]

On mdio bus the only devices are the controller and the Marvell switch.
Even increasing timeout to stupid values (>1000) I still get tx timestamp timeout sometimes...
Simultaneously I get a "tx timestamp overrun" message from Marvell driver module, maybe I can try to track that message
in driver code trying to figure out what's going on.

We are not using FEC as eth controller, we are using eqos (dw-mac/stmmac ip) instead. Do you know if there
are some bugs or patches related to ptp applications with this controller too?

Thanks for your support,
RL

-- 
Riccardo Laiolo
Leaff Engineering - Digital Solutions & Algorithms