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
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
