Re: [Linuxptp-devel] port immediately enters faulty state
On Fri, Nov 17, 2023 at 03:29:16PM -0800, Cliff Spradlin via Linuxptp-devel wrote: > I'm investigating why a port immediately enters a faulty state on > startup (and then self-recovers). > > It looks like there might be some buggy rtnl logic. This sounds familiar... wasn't there a bug in this area? Are you on the latest sha? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Fri, Nov 17, 2023 at 08:27:43PM -0800, Richard Cochran wrote: > How does this requirement improve synchronization? > > What benefit does it bring to users of the PTP? rhetorical questions :^( ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Fri, Nov 17, 2023 at 01:51:18PM +0100, Andrew Zaborowski wrote: > It is exposed on the wire in the Pdelay messages. Compliance tests > look at this. They also simulate a few hypothetical scenarios like a > domain 0 PTP port trying to communicate with a CMLDS link port since > 1588 talks about this. How does this requirement improve synchronization? What benefit does it bring to users of the PTP? Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] port immediately enters faulty state
I'm investigating why a port immediately enters a faulty state on
startup (and then self-recovers).
It looks like there might be some buggy rtnl logic.
In rtnl_link_status(), the following code is used to pass info to callers:
--
int slave_index = -1;
...
if (tb[IFLA_LINKINFO])
slave_index = rtnl_linkinfo_parse(index, tb[IFLA_LINKINFO]);
...
cb(ctx, link_up, slave_index);
---
Note that if slave_index is not set, then it will default to -1.
The problem is that in the callback port_link_status(), the passed
index is used in to check if the ethernet label has changed:
void port_link_status(void *ctx, int linkup, int ts_index) {
if (if_indextoname(ts_index, ts_label) && strcmp(old_ts_label, ts_label))
p->link_status |= TS_LABEL_CHANGED;
-
The "weird" thing is that if_indextoname() succeeds even and returns
an empty string when -1 is passed, whereas it seems like it should
return NULLPTR. Still, we should be passing the regular if index.
The effect of this is that TS_LABEL_CHANGED is set immediately and
that causes the port to go into a FAULTY state.
I think the fix here is to set slave_index to index if IFLA_LINKINFO
is not set. That said, I'm not really familiar with RTNL logic so I'm
not sure what this all means or why that is not set in this case. The
kernel version is Debian 6.5.6-1.
-cliff
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] linuxptp doesn't detect HW timestamp capability of BCM57416
On Fri, 17 Nov 2023 at 16:24, Pham, Calvin via Linuxptp-devel < linuxptp-devel@lists.sourceforge.net> wrote: > Hi Richard, > > I am running Oracle Linux 9.1 in my server which is equipped with > BCM57416. This Broadcom NIC supports IEEE-1588. But when I check if it > supports HW Timestamp, it’s not there. > > > > [root@COTS-DL380Gen11-39 ~]# ethtool -T eth0 > > Time stamping parameters for eth0: > > Capabilities: > > software-transmit > > software-receive > > software-system-clock > > *PTP Hardware Clock: none* > You need PHC (PTP hardware clock) on the NIC, to use PTP. It could be a driver issue. Looking on Broadcom page I see no reference to PTP or IEEE 1588. https://www.broadcom.com/products/ethernet-connectivity/network-adapters/bcm57416-1gbase-t-ic I can not tell you if the NIC supports PTP or not. Anyhow this mailing list is for linuxptp and not for Broadcom's NIC. You should try in forums for Broadcom NICs. Or Linux kernel modules forums. Erez Hardware Transmit Timestamp Modes: none > > Hardware Receive Filter Modes: none > > > > The kernel version is 5.14.0-284.30.0.1.el9_2.x86_64. > > The driver is bnxt_en and I cannot find its version. > > I cannot find the version of ptp module cause it is built-in, and I am > using linuxptp-2.0. > > > > Can you give some help? > > > > Thanks! > > > > Calvin P. > > > > > > > > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] linuxptp doesn't detect HW timestamp capability of BCM57416
Hi Richard, I am running Oracle Linux 9.1 in my server which is equipped with BCM57416. This Broadcom NIC supports IEEE-1588. But when I check if it supports HW Timestamp, it's not there. [root@COTS-DL380Gen11-39 ~]# ethtool -T eth0 Time stamping parameters for eth0: Capabilities: software-transmit software-receive software-system-clock PTP Hardware Clock: none Hardware Transmit Timestamp Modes: none Hardware Receive Filter Modes: none The kernel version is 5.14.0-284.30.0.1.el9_2.x86_64. The driver is bnxt_en and I cannot find its version. I cannot find the version of ptp module cause it is built-in, and I am using linuxptp-2.0. Can you give some help? Thanks! Calvin P. ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] [RFC PATCH v2 1/9] Add new TLV for CommonMeanLinkDelayInformation
On Fri, 17 Nov 2023 at 05:50, Richard Cochran wrote: > On Fri, Nov 17, 2023 at 01:41:19AM +0100, Andrew Zaborowski wrote: > > Do you want to require the user to enforce that the port numbering is > > the same between the ptp4l processes? > > No. (I meant: do you want to require that the user takes care to maintain the order of interfaces on the command line / in the config file, which I think you do -- Ok) > > > In our use case spec compliance > > is the priority, including the unique clockIdentity for CMLDS > > requirement, so we'd definitely need to be running a separate ptp4l > > process for CMLDS in this schema. > > The clockIdentity is not exposed, so what do you mean by "compliance"? It is exposed on the wire in the Pdelay messages. Compliance tests look at this. They also simulate a few hypothetical scenarios like a domain 0 PTP port trying to communicate with a CMLDS link port since 1588 talks about this. Best regards ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
