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])
On Tue, May 17, 2022 at 11:02:53AM +0200, Miroslav Lichvar wrote:
> The ice driver returns EBUSY when it fails to get a lock for the PTP
> clock, e.g. on concurrent reads. That's a random occurence and I'd not
> expect a time interval here.
Might we expect the kernel or drivers to handle retries
Hi,
On Fri, Jan 29, 2021 at 2:54 AM Grygorii Strashko
wrote:
> I've being thinking - shouldn't be implemented as new api, like
> port_pr_xx(port, ...)?
> (similar to kernel dev_xx(dev)).
The problem is:
1) There are 8 basic log level macros, and then another 8 rate-limited
macros. If I
Adds a string to the port struct that can easily identify a port.
This is intended to be used in log messages that refer to a port.
Signed-off-by: Cliff Spradlin
Change-Id: Ic45d61c05b0aa970c9caf9e17528693dc0090c31
---
port.c | 23 ++-
port.h | 7 +++
This patch improves the readability of many log messages.
Previously, only the logical port number was emitted for most
port-related log messages. Now, the interface name is included.
old: port 12: assuming the grand master role
new: port 12 (eth8): assuming the grand master role
This changes
Previously, only the logical port number was emitted for most
port-related log messages. Now, the interface name is included.
old: port 12: assuming the grand master role
new: port 12 (eth8): assuming the grand master role
Signed-off-by: Cliff Spradlin
Change-Id:
On Mon, Jan 4, 2021 at 4:28 AM Richard Cochran wrote:
> Why not refactor them all to use a helper function? The new function
could be called port2str(struct port *p) and live in port.c.
>See cid2str() in util.c as an example.
This sounds good to me. However, cid2str() uses static storage and
Previously, only the logical port number was emitted for most
port-related log messages. Now, the interface name is included.
old: port 12: assuming the grand master role
new: port 12 (eth8): assuming the grand master role
Change-Id: I38f529a4b436f96e9803920bacc605790b3a0b45
Signed-off-by: Cliff
The primary identifier in port-related debug messages is the logical
port number. For me, that seems not very useful. See for example:
ptp4l[152.283]: port 17: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
What is port 17? I have to go figure that out. Would anyone else be in
favor of
On Tue, Feb 4, 2020 at 3:06 PM Erik Hons wrote:
> Filtering these errors prevents unnecessary state transitions.
I'm not clear on why it's important to prevent unnecessary state
transitions in this situation. If the grandmaster really is suddenly
switching to a totally different timescale, isn't
Thanks everyone for investigating, testing, and patching! :)
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
> + ts += offset;
I think there is a sign error here. This line of code is attempting to
reconstruct the 'tp' variable in sysoff_estimate(). In other words, ts
should become the ethernet device's PHC timestamp at the time of the
best sample.
sysoff_measure writes
Signed-off-by: Cliff Spradlin
Change-Id: If0fd08df74e1cf108978266cd77768df4b49fb1f
---
Adds one extra missing header. I use a tool that reports when header
files are not individually compilable, which caught these missing
headers.
designated_fsm.h | 3 +++
servo_private.h | 3 +++
2 files
On Fri, Jul 27, 2018 at 1:26 PM Keller, Jacob E
wrote:
> Does the use of the vlan interface prevent hardware timestamping? Or does it
> correctly infer the real interface capabilities?
Hardware timestamping works fine with VLAN interfaces. I'm using this
capability in a production system. You
On Fri, Jul 27, 2018 at 10:14 AM Andriy Kohut wrote:
> The introduced patches add possibility of using PTP in different VLANs on a
> single L2 interface.
Why not just configure VLANs in Linux?
ptp4l already supports using VLANs, e.g. ptp4l -i "eth4.55".
On Wed, Jul 18, 2018 at 10:36 AM Patel, Vedang
wrote:
> To take advantage of the quicker startup time the profile specifies.
>
> There will be more features added later on which will further optimize
> linuxptp to run more efficiently on the automotive network. I have
> described all of the
I don't like the complexity this overlays into ptp4l's state machine.
Could you explain why you'd want to use this instead of a more standard
profile? Having a grandmaster send an announce message doesn't seem like a
significant burden to an automotive ethernet network, and ptp4l already
supports
It can be useful to see the quality of the grandmaster's clock,
especially as it changes over time (such as during GPS holdover).
This patch also collapses two redundant if statements into one.
Signed-off-by: Cliff Spradlin
---
clock.c | 12 ++--
1 file changed, 6 insertions(+), 6
If ptp4l is running as a boundary clock, and multiple master ports
share a hardware clock that is different than the slave port's
hardware clock, then phc2sys in autocfg mode will synchronize that
clock multiple times per sync loop, once per-port.
Example output when this happens:
CLOCK_REALTIME
On Wed, Jun 13, 2018 at 8:39 PM Richard Cochran
wrote:
> 1. normal - current code
> 2. check - read only ioctl; quit if setting not rich enough for the HW
time stamping mode
Yeah, I'd suggest naming these modes 'overwrite' and 'check'.
On Tue, Jun 12, 2018 at 12:40:06PM +, Geva, Erez
I feel like this would be better implemented as a config option - for
example, an option to not adjust SIOCSHWTSTAMP at all, or to have an
explicit value to set it to.
My preference would be to have an option to not adjust it. Then you could
use hwstamp_ctl or another program before running ptp4l
ptp4l runs clockcheck on an incoming PTP message before checking its
domain number. If the time on another domain is different, then
clockcheck will trigger spurious synchronization faults.
This patch reorders the logic so that clockcheck only runs on messages
in the same time domain.
If ptp4l is running as a boundary clock, and multiple master ports
share a hardware clock that is different than the master's hardware
clock, then phc2sys in autocfg mode will synchronize that clock
multiple times per sync loop, once per-port.
Example output when this happens:
CLOCK_REALTIME phc
When phc2sys synced more than one ethernet interface, such as in a JBOD
boundary clock arrangement, it was unclear which interface a line of statistics
referred to.
Previous output:
phc2sys[583.098]: sys offset -32 s2 freq +131974 delay 3871
phc2sys[583.098]: sys offset33 s2 freq
24 matches
Mail list logo
