linuxptp-users Mailing List for linuxptp (Page 111)
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-users — Open discussion on using the linuxptp software.
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
(10) |
Mar
(47) |
Apr
|
May
(26) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
(20) |
Nov
(14) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(6) |
Feb
(18) |
Mar
(27) |
Apr
(57) |
May
(32) |
Jun
(21) |
Jul
(79) |
Aug
(108) |
Sep
(13) |
Oct
(73) |
Nov
(51) |
Dec
(24) |
| 2014 |
Jan
(24) |
Feb
(41) |
Mar
(39) |
Apr
(5) |
May
(6) |
Jun
(2) |
Jul
(5) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
|
Dec
(7) |
| 2015 |
Jan
(27) |
Feb
(18) |
Mar
(37) |
Apr
(8) |
May
(13) |
Jun
(44) |
Jul
(4) |
Aug
(50) |
Sep
(35) |
Oct
(6) |
Nov
(24) |
Dec
(19) |
| 2016 |
Jan
(30) |
Feb
(30) |
Mar
(23) |
Apr
(4) |
May
(12) |
Jun
(19) |
Jul
(26) |
Aug
(13) |
Sep
|
Oct
(23) |
Nov
(37) |
Dec
(15) |
| 2017 |
Jan
(33) |
Feb
(19) |
Mar
(20) |
Apr
(43) |
May
(39) |
Jun
(23) |
Jul
(20) |
Aug
(27) |
Sep
(10) |
Oct
(15) |
Nov
|
Dec
(24) |
| 2018 |
Jan
(3) |
Feb
(10) |
Mar
(34) |
Apr
(34) |
May
(28) |
Jun
(50) |
Jul
(27) |
Aug
(75) |
Sep
(21) |
Oct
(42) |
Nov
(25) |
Dec
(31) |
| 2019 |
Jan
(39) |
Feb
(28) |
Mar
(19) |
Apr
(7) |
May
(30) |
Jun
(22) |
Jul
(54) |
Aug
(36) |
Sep
(19) |
Oct
(33) |
Nov
(36) |
Dec
(32) |
| 2020 |
Jan
(29) |
Feb
(38) |
Mar
(29) |
Apr
(30) |
May
(39) |
Jun
(45) |
Jul
(31) |
Aug
(52) |
Sep
(40) |
Oct
(8) |
Nov
(48) |
Dec
(30) |
| 2021 |
Jan
(35) |
Feb
(32) |
Mar
(23) |
Apr
(55) |
May
(43) |
Jun
(63) |
Jul
(17) |
Aug
(24) |
Sep
(9) |
Oct
(31) |
Nov
(67) |
Dec
(55) |
| 2022 |
Jan
(31) |
Feb
(48) |
Mar
(76) |
Apr
(18) |
May
(13) |
Jun
(46) |
Jul
(75) |
Aug
(54) |
Sep
(59) |
Oct
(65) |
Nov
(44) |
Dec
(7) |
| 2023 |
Jan
(38) |
Feb
(32) |
Mar
(35) |
Apr
(23) |
May
(46) |
Jun
(53) |
Jul
(18) |
Aug
(10) |
Sep
(24) |
Oct
(15) |
Nov
(40) |
Dec
(6) |
|
From: Richard C. <ric...@gm...> - 2017-01-02 15:51:09
|
On Mon, Jan 02, 2017 at 03:15:41PM +0100, Axel Holzinger wrote: > I try to cross compile linuxptpt on Xubuntu 16.04 for i686 32 bit with a > Linux 4.1.15 cross tool chain for ARM's imx6 and gcc 5.2.0, but I get some > erros and I'm not expert enough to get this resolved, unfortunately. > > Perhaps somebody reading this list has an idea what I did do wrong. > > This is the make output: > imx6@imx6-VirtualBox:~/Projects/linuxptp-1.8$ make > arm-poky-linux-gnueabi-gcc -Wall -DVER=1.8 -D_GNU_SOURCE > -DHAVE_ONESTEP_SYNC -c -o ptp4l.o ptp4l.c ... > CC=arm-poky-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon > -mtune=cortex-a9 > --sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi ... > SDKTARGETSYSROOT=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi Probably you only need to add --sysroot make EXTRA_CFLAGS=--sysroot=$SDKTARGETSYSROOT HTH, Richard |
|
From: Axel H. <aho...@gm...> - 2017-01-02 14:15:55
|
Hello all,
all the best for 2017!
I try to cross compile linuxptpt on Xubuntu 16.04 for i686 32 bit with a
Linux 4.1.15 cross tool chain for ARM's imx6 and gcc 5.2.0, but I get some
erros and I'm not expert enough to get this resolved, unfortunately.
Perhaps somebody reading this list has an idea what I did do wrong.
This is the make output:
imx6@imx6-VirtualBox:~/Projects/linuxptp-1.8$ make
arm-poky-linux-gnueabi-gcc -Wall -DVER=1.8 -D_GNU_SOURCE
-DHAVE_ONESTEP_SYNC -c -o ptp4l.o ptp4l.c
In file included from
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/lib/arm-poky-l
inux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/include-fixed/syslimits.h:7:0,
from
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/lib/arm-poky-l
inux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/include-fixed/limits.h:34,
from ptp4l.c:20:
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/lib/arm-poky-l
inux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/include-fixed/limits.h:168:61:
error: no include path in which to search for limits.h
ptp4l.c:21:19: fatal error: stdio.h: No such file or directory
compilation terminated.
<builtin>: recipe for target 'ptp4l.o' failed
make: *** [ptp4l.o] Error 1
Thanks in advance
Axel
PS: This are the locations of the asked C headers:
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/include/limits.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/include/c++/5.2.0/tr1/limits.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/include/linux/limits.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/lib/arm-poky-l
inux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/include-fixed/limits.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/lib/arm-poky-l
inux-gnueabi/gcc/arm-poky-linux-gnueabi/5.2.0/include-fixed/syslimits.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/include/stdio.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/include/bits/stdio.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/include/c++/5.2.0/tr1/stdio.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/src/debug/glibc/2.22-r0/git/include/stdio.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/src/debug/glibc/2.22-r0/git/libio/stdio.h
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueab
i/usr/src/debug/glibc/2.22-r0/git/libio/bits/stdio.h
PPS: This are the relevant (well, what I think to be relevant) environment
variables:
AR=arm-poky-linux-gnueabi-ar
ARCH=arm
AS=arm-poky-linux-gnueabi-as
CCACHE_PATH=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/bi
n:/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/bin/../i686-
pokysdk-linux/bin:/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/
usr/bin/arm-poky-linux-gnueabi:/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-p
okysdk-linux/usr/bin/arm-poky-linux-uclibc:/opt/fsl-imx-x11/4.1.15-1.2.0/sys
roots/i686-pokysdk-linux/usr/bin/arm-poky-linux-musl:
CC=arm-poky-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon
-mtune=cortex-a9
--sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-li
nux-gnueabi
CFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
CONFIG_SITE=/opt/fsl-imx-x11/4.1.15-1.2.0/site-config-cortexa9hf-vfp-neon-po
ky-linux-gnueabi
CONFIGURE_FLAGS=--target=arm-poky-linux-gnueabi
--host=arm-poky-linux-gnueabi --build=i686-linux
--with-libtool-sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp
-neon-poky-linux-gnueabi
CPP=arm-poky-linux-gnueabi-gcc -E -march=armv7-a -mfloat-abi=hard
-mfpu=neon -mtune=cortex-a9
--sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-li
nux-gnueabi
CPPFLAGS=
CROSS_COMPILE=arm-poky-linux-gnueabi-
CXX=arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon
-mtune=cortex-a9
--sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-li
nux-gnueabi
CXXFLAGS= -O2 -pipe -g -feliminate-unused-debug-types
KCFLAGS=--sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon
-poky-linux-gnueabi
LD=arm-poky-linux-gnueabi-ld
--sysroot=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-li
nux-gnueabi
LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
NM=arm-poky-linux-gnueabi-nm
OBJCOPY=arm-poky-linux-gnueabi-objcopy
OBJDUMP=arm-poky-linux-gnueabi-objdump
OECORE_ACLOCAL_OPTS=-I
/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-linux/usr/share/aclocal
OECORE_DISTRO_VERSION=4.1.15-1.2.0
OECORE_NATIVE_SYSROOT=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/i686-pokysdk-li
nux
OECORE_SDK_VERSION=4.1.15-1.2.0
OECORE_TARGET_SYSROOT=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-
neon-poky-linux-gnueabi
PWD=/home/imx6/Projects/linuxptp-1.8
RANLIB=arm-poky-linux-gnueabi-ranlib
SDKTARGETSYSROOT=/opt/fsl-imx-x11/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-
poky-linux-gnueabi
STRIP=arm-poky-linux-gnueabi-strip
TARGET_PREFIX=arm-poky-linux-gnueabi-
|
|
From: Rich S. <sch...@gm...> - 2016-12-30 16:39:25
|
I am sorry to report that the proposed fix to the problem SLAVE to FAULTY
on FAULT_DETECTED (FT_UNSPECIFIED),
shown below did not resolve the issue.
Red Hat LINUX: with source kernel 4.9.0
Intel igb driver: 5.4.0-k
Prior to compiling the kernel:
cd /usr/src/linux-4.9/drivers/net/ethernet/intel/igb
Edit igb_main.c and comment out at line 5715:
/* wr32(E1000_TSICR, ack); */
Ran fine for a while then failed as shown below. Able to restore by
killing ptp4l, rmmod igb; modprobe igb, restart ptp4l.
Here is the ptp4l log after running successfully for 26.65 hours:
ptp4l[101975.294]: master offset -58 s2 freq +831 path delay
1632
ptp4l[101976.294]: linreg: points 8 slope 0.999999144 intercept 3 err 25
ptp4l[101976.294]: master offset -10 s2 freq +853 path delay
1632
ptp4l[101976.900]: port 1: delay timeout
ptp4l[101976.910]: timed out while polling for tx timestamp
ptp4l[101976.910]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[101976.910]: port 1: send delay request failed
ptp4l[101976.910]: port 1: SLAVE to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[101976.910]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[101992.911]: clearing fault on port 1
ptp4l[101992.911]: config item enp1s0f0.logMinDelayReqInterval is 2
ptp4l[101992.911]: config item enp1s0f0.logAnnounceInterval is 0
ptp4l[101992.911]: config item enp1s0f0.announceReceiptTimeout is 4
ptp4l[101992.911]: config item enp1s0f0.syncReceiptTimeout is 0
ptp4l[101992.911]: config item enp1s0f0.transportSpecific is 0
ptp4l[101992.911]: config item enp1s0f0.logSyncInterval is 0
ptp4l[101992.911]: config item enp1s0f0.logMinPdelayReqInterval is 2
ptp4l[101992.911]: config item enp1s0f0.neighborPropDelayThresh is 20000000
ptp4l[101992.911]: config item enp1s0f0.min_neighbor_prop_delay is -20000000
ptp4l[101992.911]: config item enp1s0f0.udp_ttl is 1
ptp4l[101992.915]: driver changed our HWTSTAMP options
ptp4l[101992.915]: tx_type 1 not 1
ptp4l[101992.915]: rx_filter 1 not 12
ptp4l[101992.915]: config item (null).dscp_event is 0
ptp4l[101992.915]: config item (null).dscp_general is 0
ptp4l[101992.915]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[101993.294]: port 1: setting asCapable
ptp4l[101993.299]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[101995.299]: selected best master clock 0019dd.fffe.00085c
ptp4l[101995.299]: foreign master not using PTP timescale
ptp4l[101995.299]: running in a temporal vortex
ptp4l[101995.299]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[101996.295]: linreg: points 8 slope 0.999999153 intercept 142 err 29
ptp4l[101996.295]: master offset -150 s2 freq +705 path delay
1632
ptp4l[101996.295]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[101996.635]: port 1: delay timeout
ptp4l[101996.645]: timed out while polling for tx timestamp
ptp4l[101996.645]: increasing tx_timestamp_timeout may correct this issue,
but it is likely caused by a driver bug
ptp4l[101996.645]: port 1: send delay request failed
ptp4l[101996.645]: port 1: SLAVE to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[101996.645]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[102012.645]: clearing fault on port 1
. . .
Richard Schmidt, CTR
Time Service Dept.
US Naval Observatory
On Wed, Dec 21, 2016 at 4:53 PM, Richard Cochran <ric...@gm...>
wrote:
> On Wed, Dec 21, 2016 at 04:26:16PM -0500, Rich Schmidt wrote:
> > I've been testing linuxptp for about a year (now version 1.8) and am
> still
> > seeing the following failure always after 8 or more days of successful
> > operation:
>
> > ptp4l[4906544.301]: port 1: delay timeout
> > ptp4l[4906545.303]: timed out while polling for tx timestamp
> > ptp4l[4906545.303]: increasing tx_timestamp_timeout may correct this
> issue,
> > but it is likely cause
> > d by a driver bug
> > ptp4l[4906545.303]: port 1: send delay request failed
>
> I don't recalling seeing this myself, but still this is the second
> such igb failure report I have received recently.
>
> I wonder whether the incorrect double TSICR acknowledge is the root
> cause. In igb_main.c we have:
>
> static void igb_tsync_interrupt(struct igb_adapter *adapter)
> {
> struct e1000_hw *hw = &adapter->hw;
> struct ptp_clock_event event;
> struct timespec64 ts;
> u32 ack = 0, tsauxc, sec, nsec, tsicr = rd32(E1000_TSICR);
>
> ...
>
> /* acknowledge the interrupts */
> wr32(E1000_TSICR, ack);
> }
>
> According to the datasheet, the first rd32() should already
> acknowledge the interrupts, but the 82580 (iirc) has a bug that
> requires the additional wr32().
>
> Try removing that last line, and see if things improve...
>
> Thanks,
> Richard
>
--
"If you want to build a ship, don’t drum up people to collect wood and
don’t assign them tasks and work, but rather teach them to long for the
endless immensity of the sea."
- *Antoine de Saint-Exupéry*
|
|
From: Richard C. <ric...@gm...> - 2016-12-22 18:14:31
|
On Thu, Dec 22, 2016 at 11:33:34AM -0500, Rich Schmidt wrote:
> Richard, I'm lost already. My igb driver 5.3.5.4 does not have
> igb_tsync_interrupt().
> See attached source for igb_main.c. Am I supposed to be using some other
> version of the igb driver?
Well, you can use anything you want, but that file is rather out of
date WRT the mainline Linux driver. It lacks this change
commit 61d7f75f45231e4a2f2ab7d975555f55f0019800
Author: Richard Cochran <ric...@gm...>
Date: Fri Nov 21 20:51:10 2014 +0000
igb: refactor time sync interrupt handling
The code that handles the time sync interrupt is repeated in three
different places. This patch refactors the identical code blocks into
a single helper function.
which was merged in v4.0. I recommend using a recent mainline kernel version.
Anyhow, your version has identical handling in three places:
> static irqreturn_t igb_msix_other(int irq, void *data)
> {
...
> #ifdef HAVE_PTP_1588_CLOCK
> if (icr & E1000_ICR_TS) {
> u32 tsicr = E1000_READ_REG(hw, E1000_TSICR);
>
> if (tsicr & E1000_TSICR_TXTS) {
> /* acknowledge the interrupt */
> E1000_WRITE_REG(hw, E1000_TSICR, E1000_TSICR_TXTS);
> /* retrieve hardware timestamp */
> schedule_work(&adapter->ptp_tx_work);
> }
> }
> #endif /* HAVE_PTP_1588_CLOCK */
...
> return IRQ_HANDLED;
> }
> static irqreturn_t igb_intr_msi(int irq, void *data)
> {
...
> #ifdef HAVE_PTP_1588_CLOCK
> if (icr & E1000_ICR_TS) {
> u32 tsicr = E1000_READ_REG(hw, E1000_TSICR);
>
> if (tsicr & E1000_TSICR_TXTS) {
> /* acknowledge the interrupt */
> E1000_WRITE_REG(hw, E1000_TSICR, E1000_TSICR_TXTS);
> /* retrieve hardware timestamp */
> schedule_work(&adapter->ptp_tx_work);
> }
> }
> #endif /* HAVE_PTP_1588_CLOCK */
...
> return IRQ_HANDLED;
> }
> static irqreturn_t igb_intr(int irq, void *data)
> {
...
> #ifdef HAVE_PTP_1588_CLOCK
> if (icr & E1000_ICR_TS) {
> u32 tsicr = E1000_READ_REG(hw, E1000_TSICR);
>
> if (tsicr & E1000_TSICR_TXTS) {
> /* acknowledge the interrupt */
> E1000_WRITE_REG(hw, E1000_TSICR, E1000_TSICR_TXTS);
> /* retrieve hardware timestamp */
> schedule_work(&adapter->ptp_tx_work);
> }
> }
> #endif /* HAVE_PTP_1588_CLOCK */
..
> return IRQ_HANDLED;
> }
Try deleting the lines
> /* acknowledge the interrupt */
> E1000_WRITE_REG(hw, E1000_TSICR, E1000_TSICR_TXTS);
in each of the three cases.
HTH,
Richard
|
|
From: 糸川直樹 / ITOKAWA，N. <nao...@hi...> - 2016-12-22 17:32:52
|
Hello, I could make ptp4l working on Raspberry Pi, then I'd like to write about it. - Raspberry Pi 3 Model B - write image of Raspbian Jessie with Pixel to microSD - installed linuxPTP v1.8 - installed ethtool *** Rebuilding kernel configuration *** (1) Make directory of kernel $ cd $ mkdir kernel $ cd kernel (2) Download kernel $ git clone --depth=1 https://github.com/raspberrypi/linux $ sudo apt-get update $ sudo apt-get install bc (3) Configuration of kernal $ cd linux $ KERNEL=kernel7 $ make bcm2709_defconfig (4) Configuration with menuconfig $ sudo apt-get install libncurses5-dev $ make menuconfig Activate following three configuration with "menu-config" CONFIG_PPS CONFIG_NETWORK_PHY_TIMESTAMPING PTP_1588_CLOCK Save configuration. (5) Modify ethernet driver Search "drivers/net/usb/smsc95xx.c", and edit it with vi editor. Add a sentence " .get_ts_info = ethtool_op_get_ts_info," to end of " smsc95xx_ethtool_ops = " static const struct ethtool_ops smsc95xx_ethtool_ops = { .get_link = usbnet_get_link, .nway_reset = usbnet_nway_reset, .get_drvinfo = usbnet_get_drvinfo, .get_msglevel = usbnet_get_msglevel, .set_msglevel = usbnet_set_msglevel, .get_settings = smsc95xx_get_settings, .set_settings = smsc95xx_set_settings, .get_eeprom_len = smsc95xx_ethtool_get_eeprom_len, .get_eeprom = smsc95xx_ethtool_get_eeprom, .set_eeprom = smsc95xx_ethtool_set_eeprom, .get_regs_len = smsc95xx_ethtool_getregslen, .get_regs = smsc95xx_ethtool_getregs, .get_wol = smsc95xx_ethtool_get_wol, .set_wol = smsc95xx_ethtool_set_wol, .get_ts_info = ethtool_op_get_ts_info, }; (6) Name extraversion of rebuilding kernel $ cd ~/kernel/linux $ vi Makefile edit extraversion in Makefile such as; EXTRAVERSION = ptprpi (7) Building kernel $ make -j4 zImage modules dtbs $ sudo make modules_install $ sudo cp arch/arm/boot/dts/*.dtb /boot/ $ sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/ $ sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/ $ sudo scripts/mkknlimg arch/arm/boot/zImage /boot/$KERNEL.img (8) Reboot in new kernel $ sudo shutdown -r now ---------------------------- In my case, ptp4l on rpi has become working with these procedure. Thank you. Best Regards, Naoki Itokawa |
|
From: Rich S. <sch...@gm...> - 2016-12-22 16:33:56
|
ptp4l[4906520.702]: linreg: points 16 slope 0.999999311 intercept 7 err 28
ptp4l[4906520.702]: master offset 5 s2 freq +682 path delay 1640
ptp4l[4906521.702]: linreg: points 16 slope 0.999999311 intercept -0 err 28
ptp4l[4906521.702]: master offset 2 s2 freq +689 path delay 1640
ptp4l[4906522.702]: linreg: points 16 slope 0.999999313 intercept 12 err 28
ptp4l[4906522.702]: master offset -48 s2 freq +675 path delay 1640
ptp4l[4906523.702]: linreg: points 16 slope 0.999999312 intercept 0 err 28
ptp4l[4906523.702]: master offset -4 s2 freq +687 path delay 1640
ptp4l[4906524.016]: port 1: delay timeout
ptp4l[4906524.032]: delay filtered 1644 raw 1649
ptp4l[4906524.702]: linreg: points 16 slope 0.999999313 intercept -1 err 28
ptp4l[4906524.702]: master offset 24 s2 freq +688 path delay 1644
ptp4l[4906525.582]: port 1: delay timeout
ptp4l[4906525.592]: delay filtered 1644 raw 1676
ptp4l[4906525.702]: linreg: points 16 slope 0.999999313 intercept 2 err 28
ptp4l[4906525.702]: master offset -25 s2 freq +685 path delay 1644
ptp4l[4906526.702]: linreg: points 16 slope 0.999999315 intercept 18 err 29
ptp4l[4906526.702]: master offset -71 s2 freq +668 path delay 1644
ptp4l[4906527.702]: linreg: points 16 slope 0.999999315 intercept -0 err 28
ptp4l[4906527.702]: master offset 21 s2 freq +685 path delay 1644
ptp4l[4906528.702]: linreg: points 16 slope 0.999999316 intercept 3 err 28
ptp4l[4906528.702]: master offset 15 s2 freq +682 path delay 1644
ptp4l[4906529.702]: linreg: points 16 slope 0.999999316 intercept 3 err 28
ptp4l[4906529.703]: master offset -27 s2 freq +681 path delay 1644
ptp4l[4906530.703]: linreg: points 16 slope 0.999999316 intercept 0 err 28
ptp4l[4906530.703]: master offset 12 s2 freq +683 path delay 1644
ptp4l[4906531.703]: linreg: points 16 slope 0.999999316 intercept 1 err 28
ptp4l[4906531.703]: master offset -32 s2 freq +683 path delay 1644
ptp4l[4906531.867]: port 1: delay timeout
ptp4l[4906531.898]: delay filtered 1647 raw 1657
ptp4l[4906532.703]: linreg: points 16 slope 0.999999317 intercept 17 err 29
ptp4l[4906532.703]: master offset -78 s2 freq +666 path delay 1647
ptp4l[4906533.703]: linreg: points 16 slope 0.999999319 intercept 11 err 29
ptp4l[4906533.703]: master offset -24 s2 freq +670 path delay 1647
ptp4l[4906534.703]: linreg: points 16 slope 0.999999320 intercept 6 err 29
ptp4l[4906534.703]: master offset -14 s2 freq +674 path delay 1647
ptp4l[4906535.703]: linreg: points 16 slope 0.999999322 intercept 15 err 29
ptp4l[4906535.703]: master offset -48 s2 freq +663 path delay 1647
ptp4l[4906536.703]: linreg: points 16 slope 0.999999323 intercept 17 err 30
ptp4l[4906536.703]: master offset -72 s2 freq +660 path delay 1647
ptp4l[4906537.703]: linreg: points 16 slope 0.999999323 intercept -5 err 30
ptp4l[4906537.703]: master offset 28 s2 freq +682 path delay 1647
ptp4l[4906538.703]: linreg: points 16 slope 0.999999325 intercept 10 err 29
ptp4l[4906538.703]: master offset -14 s2 freq +666 path delay 1647
ptp4l[4906539.478]: port 1: delay timeout
ptp4l[4906539.503]: delay filtered 1650 raw 1667
ptp4l[4906539.703]: linreg: points 16 slope 0.999999325 intercept 3 err 29
ptp4l[4906539.703]: master offset -3 s2 freq +671 path delay 1650
ptp4l[4906540.701]: port 1: delay timeout
ptp4l[4906540.704]: linreg: points 16 slope 0.999999327 intercept 15 err 30
ptp4l[4906540.704]: master offset -75 s2 freq +658 path delay 1650
ptp4l[4906540.738]: delay filtered 1653 raw 15548
ptp4l[4906541.703]: linreg: points 16 slope 0.999999328 intercept 7 err 30
ptp4l[4906541.703]: master offset -17 s2 freq +666 path delay 1653
ptp4l[4906542.703]: linreg: points 16 slope 0.999999330 intercept 19 err 30
ptp4l[4906542.703]: master offset -43 s2 freq +651 path delay 1653
ptp4l[4906543.703]: linreg: points 16 slope 0.999999331 intercept 4 err 30
ptp4l[4906543.703]: master offset -14 s2 freq +666 path delay 1653
ptp4l[4906544.301]: port 1: delay timeout
ptp4l[4906545.303]: timed out while polling for tx timestamp
ptp4l[4906545.303]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[4906545.303]: port 1: send delay request failed
ptp4l[4906545.303]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[4906545.303]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[4906561.303]: clearing fault on port 1
ptp4l[4906561.303]: config item enp1s0f0.logMinDelayReqInterval is 2
ptp4l[4906561.303]: config item enp1s0f0.logAnnounceInterval is 0
ptp4l[4906561.303]: config item enp1s0f0.announceReceiptTimeout is 4
ptp4l[4906561.303]: config item enp1s0f0.syncReceiptTimeout is 0
ptp4l[4906561.303]: config item enp1s0f0.transportSpecific is 0
ptp4l[4906561.303]: config item enp1s0f0.logSyncInterval is 0
ptp4l[4906561.303]: config item enp1s0f0.logMinPdelayReqInterval is 2
ptp4l[4906561.303]: config item enp1s0f0.neighborPropDelayThresh is 20000000
ptp4l[4906561.303]: config item enp1s0f0.min_neighbor_prop_delay is -20000000
ptp4l[4906561.303]: config item enp1s0f0.udp_ttl is 1
ptp4l[4906561.305]: driver changed our HWTSTAMP options
ptp4l[4906561.305]: tx_type 1 not 1
ptp4l[4906561.305]: rx_filter 1 not 12
ptp4l[4906561.305]: config item (null).dscp_event is 0
ptp4l[4906561.305]: config item (null).dscp_general is 0
ptp4l[4906561.305]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[4906561.703]: port 1: setting asCapable
ptp4l[4906561.713]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[4906563.713]: selected best master clock 0019dd.fffe.00085c
ptp4l[4906563.713]: foreign master not using PTP timescale
ptp4l[4906563.713]: running in a temporal vortex
ptp4l[4906563.713]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4906564.704]: linreg: points 8 slope 0.999999339 intercept 123 err 31
ptp4l[4906564.704]: master offset -120 s2 freq +538 path delay 1653
ptp4l[4906564.704]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[4906565.704]: linreg: points 8 slope 0.999999340 intercept 29 err 31
ptp4l[4906565.704]: master offset -59 s2 freq +631 path delay 1653
ptp4l[4906566.704]: linreg: points 8 slope 0.999999340 intercept 3 err 31
ptp4l[4906566.704]: master offset -10 s2 freq +656 path delay 1653
ptp4l[4906567.704]: linreg: points 8 slope 0.999999339 intercept -16 err 31
ptp4l[4906567.704]: master offset 53 s2 freq +676 path delay 1653
ptp4l[4906567.720]: port 1: delay timeout
ptp4l[4906568.721]: timed out while polling for tx timestamp
ptp4l[4906568.721]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[4906568.721]: port 1: send delay request failed
ptp4l[4906568.721]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[4906568.721]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[4906584.722]: clearing fault on port 1
ptp4l[4906584.722]: config item enp1s0f0.logMinDelayReqInterval is 2
ptp4l[4906584.722]: config item enp1s0f0.logAnnounceInterval is 0
ptp4l[4906584.722]: config item enp1s0f0.announceReceiptTimeout is 4
ptp4l[4906584.722]: config item enp1s0f0.syncReceiptTimeout is 0
ptp4l[4906584.722]: config item enp1s0f0.transportSpecific is 0
ptp4l[4906584.722]: config item enp1s0f0.logSyncInterval is 0
ptp4l[4906584.722]: config item enp1s0f0.logMinPdelayReqInterval is 2
ptp4l[4906584.722]: config item enp1s0f0.neighborPropDelayThresh is 20000000
ptp4l[4906584.722]: config item enp1s0f0.min_neighbor_prop_delay is -20000000
ptp4l[4906584.722]: config item enp1s0f0.udp_ttl is 1
ptp4l[4906584.722]: driver changed our HWTSTAMP options
ptp4l[4906584.722]: tx_type 1 not 1
ptp4l[4906584.722]: rx_filter 1 not 12
ptp4l[4906584.722]: config item (null).dscp_event is 0
ptp4l[4906584.722]: config item (null).dscp_general is 0
ptp4l[4906584.722]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[4906585.704]: port 1: setting asCapable
ptp4l[4906585.714]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[4906587.714]: selected best master clock 0019dd.fffe.00085c
ptp4l[4906587.714]: foreign master not using PTP timescale
ptp4l[4906587.714]: running in a temporal vortex
ptp4l[4906587.714]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4906588.705]: linreg: points 8 slope 0.999999345 intercept 506 err 37
ptp4l[4906588.705]: master offset -645 s2 freq +149 path delay 1653
ptp4l[4906588.705]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[4906589.705]: linreg: points 8 slope 0.999999347 intercept 81 err 40
ptp4l[4906589.705]: master offset -194 s2 freq +572 path delay 1653
ptp4l[4906590.705]: linreg: points 8 slope 0.999999351 intercept 67 err 43
ptp4l[4906590.705]: master offset -166 s2 freq +582 path delay 1653
ptp4l[4906591.705]: linreg: points 8 slope 0.999999356 intercept 62 err 43
ptp4l[4906591.705]: master offset -68 s2 freq +582 path delay 1653
ptp4l[4906592.417]: port 1: delay timeout
ptp4l[4906593.418]: timed out while polling for tx timestamp
ptp4l[4906593.418]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[4906593.418]: port 1: send delay request failed
ptp4l[4906593.418]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[4906593.418]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[4906609.419]: clearing fault on port 1
ptp4l[4906609.419]: config item enp1s0f0.logMinDelayReqInterval is 2
ptp4l[4906609.419]: config item enp1s0f0.logAnnounceInterval is 0
ptp4l[4906609.419]: config item enp1s0f0.announceReceiptTimeout is 4
ptp4l[4906609.419]: config item enp1s0f0.syncReceiptTimeout is 0
ptp4l[4906609.419]: config item enp1s0f0.transportSpecific is 0
ptp4l[4906609.419]: config item enp1s0f0.logSyncInterval is 0
ptp4l[4906609.419]: config item enp1s0f0.logMinPdelayReqInterval is 2
ptp4l[4906609.419]: config item enp1s0f0.neighborPropDelayThresh is 20000000
ptp4l[4906609.419]: config item enp1s0f0.min_neighbor_prop_delay is -20000000
ptp4l[4906609.419]: config item enp1s0f0.udp_ttl is 1
ptp4l[4906609.419]: driver changed our HWTSTAMP options
ptp4l[4906609.419]: tx_type 1 not 1
ptp4l[4906609.419]: rx_filter 1 not 12
ptp4l[4906609.419]: config item (null).dscp_event is 0
ptp4l[4906609.419]: config item (null).dscp_general is 0
ptp4l[4906609.419]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[4906609.705]: port 1: setting asCapable
ptp4l[4906609.715]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[4906611.715]: selected best master clock 0019dd.fffe.00085c
ptp4l[4906611.715]: foreign master not using PTP timescale
ptp4l[4906611.715]: running in a temporal vortex
ptp4l[4906611.715]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4906612.706]: linreg: points 8 slope 0.999999361 intercept -1042 err 49
ptp4l[4906612.706]: master offset 889 s2 freq +1680 path delay 1653
ptp4l[4906612.706]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[4906613.594]: port 1: delay timeout
ptp4l[4906614.596]: timed out while polling for tx timestamp
ptp4l[4906614.596]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[4906614.596]: port 1: send delay request failed
ptp4l[4906614.596]: port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[4906614.596]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[4906630.596]: clearing fault on port 1
ptp4l[4906630.596]: config item enp1s0f0.logMinDelayReqInterval is 2
ptp4l[4906630.596]: config item enp1s0f0.logAnnounceInterval is 0
ptp4l[4906630.596]: config item enp1s0f0.announceReceiptTimeout is 4
ptp4l[4906630.596]: config item enp1s0f0.syncReceiptTimeout is 0
ptp4l[4906630.596]: config item enp1s0f0.transportSpecific is 0
ptp4l[4906630.596]: config item enp1s0f0.logSyncInterval is 0
ptp4l[4906630.596]: config item enp1s0f0.logMinPdelayReqInterval is 2
ptp4l[4906630.596]: config item enp1s0f0.neighborPropDelayThresh is 20000000
ptp4l[4906630.596]: config item enp1s0f0.min_neighbor_prop_delay is -20000000
ptp4l[4906630.596]: config item enp1s0f0.udp_ttl is 1
ptp4l[4906630.597]: driver changed our HWTSTAMP options
ptp4l[4906630.597]: tx_type 1 not 1
ptp4l[4906630.597]: rx_filter 1 not 12
ptp4l[4906630.597]: config item (null).dscp_event is 0
ptp4l[4906630.597]: config item (null).dscp_general is 0
ptp4l[4906630.597]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[4906630.705]: port 1: setting asCapable
ptp4l[4906630.716]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[4906632.716]: selected best master clock 0019dd.fffe.00085c
ptp4l[4906632.716]: foreign master not using PTP timescale
ptp4l[4906632.716]: running in a temporal vortex
ptp4l[4906632.716]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4906633.707]: linreg: points 4 slope 0.999999378 intercept 21467 err 58
ptp4l[4906633.707]: master offset -21531 s2 freq -20845 path delay 1653
ptp4l[4906633.707]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[4906634.205]: port 1: delay timeout
ptp4l[4906635.206]: timed out while polling for tx timestamp
ptp4l[4906635.206]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug |
|
From: Richard C. <ric...@gm...> - 2016-12-21 21:53:46
|
On Wed, Dec 21, 2016 at 04:26:16PM -0500, Rich Schmidt wrote:
> I've been testing linuxptp for about a year (now version 1.8) and am still
> seeing the following failure always after 8 or more days of successful
> operation:
> ptp4l[4906544.301]: port 1: delay timeout
> ptp4l[4906545.303]: timed out while polling for tx timestamp
> ptp4l[4906545.303]: increasing tx_timestamp_timeout may correct this issue,
> but it is likely cause
> d by a driver bug
> ptp4l[4906545.303]: port 1: send delay request failed
I don't recalling seeing this myself, but still this is the second
such igb failure report I have received recently.
I wonder whether the incorrect double TSICR acknowledge is the root
cause. In igb_main.c we have:
static void igb_tsync_interrupt(struct igb_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
struct ptp_clock_event event;
struct timespec64 ts;
u32 ack = 0, tsauxc, sec, nsec, tsicr = rd32(E1000_TSICR);
...
/* acknowledge the interrupts */
wr32(E1000_TSICR, ack);
}
According to the datasheet, the first rd32() should already
acknowledge the interrupts, but the 82580 (iirc) has a bug that
requires the additional wr32().
Try removing that last line, and see if things improve...
Thanks,
Richard
|
|
From: Rich S. <sch...@gm...> - 2016-12-21 21:26:25
|
I've been testing linuxptp for about a year (now version 1.8) and am still
seeing the following failure always after 8 or more days of successful
operation:
port 1: send delay request failed
port 1: SLAVE to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
It then goes into an endless loop of attempting to clear, getting some
good master offsets, then faulting again. *Killing and restarting ptp4l
does not fix the problem. It requires a power cycle of the server (power
cycle of the NIC). *
That makes me suspect the igb driver itself.
In the latest test linuxptp ran for *14.7 days* before FAULTing, leading me
to wonder if there is some memory leak in the igb driver? Is igb driver
5.3.5.4 supported by linuxptp? Should I be using an earlier version?
Host: Cisco C240M4 Red Hat Enterprise Linux 7: 3.10.0-327.28.2.el7.x86_64
NIC: i350
ethtool -T enp1s0f0
Time stamping parameters for enp1s0f0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
all (HWTSTAMP_FILTER_ALL)
ethtool -i enp1s0f0
driver: igb
version: 5.3.5.4
firmware-version: 1.63, 0x80000c25, 0.384.130
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
Valgrind finds no memory leak in ptp4l:
==3544== HEAP SUMMARY:
==3544== in use at exit: 0 bytes in 0 blocks
==3544== total heap usage: 200 allocs, 200 frees, 40,202 bytes allocated
==3544==
==3544== All heap blocks were freed -- no leaks are possible
==3544==
==3544== For counts of detected and suppressed errors, rerun with: -v
==3544== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)
Example output running fine then generating FAULT:
ptp4l[4906535.703]: linreg: points 16 slope 0.999999322 intercept 15 err 29
ptp4l[4906535.703]: master offset -48 s2 freq +663 path delay
1647
ptp4l[4906536.703]: linreg: points 16 slope 0.999999323 intercept 17 err 30
ptp4l[4906536.703]: master offset -72 s2 freq +660 path delay
1647
ptp4l[4906537.703]: linreg: points 16 slope 0.999999323 intercept -5 err 30
ptp4l[4906537.703]: master offset 28 s2 freq +682 path delay
1647
ptp4l[4906538.703]: linreg: points 16 slope 0.999999325 intercept 10 err 29
ptp4l[4906538.703]: master offset -14 s2 freq +666 path delay
1647
ptp4l[4906539.478]: port 1: delay timeout
ptp4l[4906539.503]: delay filtered 1650 raw 1667
ptp4l[4906539.703]: linreg: points 16 slope 0.999999325 intercept 3 err 29
ptp4l[4906539.703]: master offset -3 s2 freq +671 path delay
1650
ptp4l[4906540.701]: port 1: delay timeout
ptp4l[4906540.704]: linreg: points 16 slope 0.999999327 intercept 15 err 30
ptp4l[4906540.704]: master offset -75 s2 freq +658 path delay
1650
ptp4l[4906540.738]: delay filtered 1653 raw 15548
ptp4l[4906541.703]: linreg: points 16 slope 0.999999328 intercept 7 err 30
ptp4l[4906541.703]: master offset -17 s2 freq +666 path delay
1653
ptp4l[4906542.703]: linreg: points 16 slope 0.999999330 intercept 19 err 30
ptp4l[4906542.703]: master offset -43 s2 freq +651 path delay
1653
ptp4l[4906543.703]: linreg: points 16 slope 0.999999331 intercept 4 err 30
ptp4l[4906543.703]: master offset -14 s2 freq +666 path delay
1653
ptp4l[4906544.301]: port 1: delay timeout
ptp4l[4906545.303]: timed out while polling for tx timestamp
ptp4l[4906545.303]: increasing tx_timestamp_timeout may correct this issue,
but it is likely cause
d by a driver bug
ptp4l[4906545.303]: port 1: send delay request failed
ptp4l[4906545.303]: port 1: SLAVE to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[4906545.303]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[4906561.303]: clearing fault on port 1
ptp4l[4906561.303]: config item enp1s0f0.logMinDelayReqInterval is 2
ptp4l[4906561.303]: config item enp1s0f0.logAnnounceInterval is 0
ptp4l[4906561.303]: config item enp1s0f0.announceReceiptTimeout is 4
ptp4l[4906561.303]: config item enp1s0f0.syncReceiptTimeout is 0
ptp4l[4906561.303]: config item enp1s0f0.transportSpecific is 0
ptp4l[4906561.303]: config item enp1s0f0.logSyncInterval is 0
ptp4l[4906561.303]: config item enp1s0f0.logMinPdelayReqInterval is 2
ptp4l[4906561.303]: config item enp1s0f0.neighborPropDelayThresh is 20000000
ptp4l[4906561.303]: config item enp1s0f0.min_neighbor_prop_delay is
-20000000
ptp4l[4906561.303]: config item enp1s0f0.udp_ttl is 1
ptp4l[4906561.305]: driver changed our HWTSTAMP options
ptp4l[4906561.305]: tx_type 1 not 1
ptp4l[4906561.305]: rx_filter 1 not 12
ptp4l[4906561.305]: config item (null).dscp_event is 0
ptp4l[4906561.305]: config item (null).dscp_general is 0
ptp4l[4906561.305]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[4906561.703]: port 1: setting asCapable
ptp4l[4906561.713]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[4906563.713]: selected best master clock 0019dd.fffe.00085c
ptp4l[4906563.713]: foreign master not using PTP timescale
ptp4l[4906563.713]: running in a temporal vortex
ptp4l[4906563.713]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4906564.704]: linreg: points 8 slope 0.999999339 intercept 123 err 31
ptp4l[4906564.704]: master offset -120 s2 freq +538 path delay
1653
ptp4l[4906564.704]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[4906565.704]: linreg: points 8 slope 0.999999340 intercept 29 err 31
ptp4l[4906565.704]: master offset -59 s2 freq +631 path delay
1653
ptp4l[4906566.704]: linreg: points 8 slope 0.999999340 intercept 3 err 31
ptp4l[4906566.704]: master offset -10 s2 freq +656 path delay
1653
ptp4l[4906567.704]: linreg: points 8 slope 0.999999339 intercept -16 err 31
ptp4l[4906567.704]: master offset 53 s2 freq +676 path delay
1653
ptp4l[4906567.720]: port 1: delay timeout
ptp4l[4906568.721]: timed out while polling for tx timestamp
ptp4l[4906568.721]: increasing tx_timestamp_timeout may correct this issue,
but it is likely cause
d by a driver bug
ptp4l[4906568.721]: port 1: send delay request failed
ptp4l[4906568.721]: port 1: SLAVE to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[4906568.721]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[4906584.722]: clearing fault on port 1
ptp4l[4906584.722]: config item enp1s0f0.logMinDelayReqInterval is 2
ptp4l[4906584.722]: config item enp1s0f0.logAnnounceInterval is 0
ptp4l[4906584.722]: config item enp1s0f0.announceReceiptTimeout is 4
ptp4l[4906584.722]: config item enp1s0f0.syncReceiptTimeout is 0
ptp4l[4906584.722]: config item enp1s0f0.transportSpecific is 0
ptp4l[4906584.722]: config item enp1s0f0.logSyncInterval is 0
ptp4l[4906584.722]: config item enp1s0f0.logMinPdelayReqInterval is 2
ptp4l[4906584.722]: config item enp1s0f0.neighborPropDelayThresh is 20000000
ptp4l[4906584.722]: config item enp1s0f0.min_neighbor_prop_delay is
-20000000
ptp4l[4906584.722]: config item enp1s0f0.udp_ttl is 1
ptp4l[4906584.722]: driver changed our HWTSTAMP options
ptp4l[4906584.722]: tx_type 1 not 1
ptp4l[4906584.722]: rx_filter 1 not 12
ptp4l[4906584.722]: config item (null).dscp_event is 0
ptp4l[4906584.722]: config item (null).dscp_general is 0
ptp4l[4906584.722]: port 1: FAULTY to LISTENING on FAULT_CLEARED
ptp4l[4906585.704]: port 1: setting asCapable
ptp4l[4906585.714]: port 1: new foreign master 0019dd.fffe.00085c-1
ptp4l[4906587.714]: selected best master clock 0019dd.fffe.00085c
ptp4l[4906587.714]: foreign master not using PTP timescale
ptp4l[4906587.714]: running in a temporal vortex
ptp4l[4906587.714]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4906588.705]: linreg: points 8 slope 0.999999345 intercept 506 err 37
ptp4l[4906588.705]: master offset -645 s2 freq +149 path delay
1653
ptp4l[4906588.705]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[4906589.705]: linreg: points 8 slope 0.999999347 intercept 81 err 40
ptp4l[4906589.705]: master offset -194 s2 freq +572 path delay
1653
ptp4l[4906590.705]: linreg: points 8 slope 0.999999351 intercept 67 err 43
ptp4l[4906590.705]: master offset -166 s2 freq +582 path delay
1653
ptp4l[4906591.705]: linreg: points 8 slope 0.999999356 intercept 62 err 43
ptp4l[4906591.705]: master offset -68 s2 freq +582 path delay
1653
ptp4l[4906592.417]: port 1: delay timeout
ptp4l[4906593.418]: timed out while polling for tx timestamp
ptp4l[4906593.418]: increasing tx_timestamp_timeout may correct this issue,
but it is likely cause
d by a driver bug
ptp4l[4906593.418]: port 1: send delay request failed
ptp4l[4906593.418]: port 1: SLAVE to FAULTY on FAULT_DETECTED
(FT_UNSPECIFIED)
ptp4l[4906593.418]: waiting 2^{4} seconds to clear fault on port 1
ptp4l[4906609.419]: clearing fault on port 1
Rich Schmidt, CTR, USNO
--
"If you want to build a ship, don’t drum up people to collect wood and
don’t assign them tasks and work, but rather teach them to long for the
endless immensity of the sea."
- *Antoine de Saint-Exupéry*
|
|
From: Taber, A. <ala...@lm...> - 2016-12-19 16:40:40
|
Hi Stan, Thanks for the reverse path filtering "relaxed" setting. That did the trick! Linux boxes are now listening to the GrandMaster clock. And everyone else, thanks for all your suggestions! I know a lot more now than I did before about how to set up PTP here, and I appreciate you taking the time to respond. Best regards, Alan -----Original Message----- From: Moravec, Stanislav (ERT) [mailto:sta...@hp...] Sent: Friday, December 16, 2016 2:51 AM To: Keller, Jacob E <jac...@in...>; Taber, Alan (US) <ala...@lm...>; Richard Cochran <ric...@gm...> Cc: lin...@li... Subject: EXTERNAL: RE: [Linuxptp-users] EXTERNAL: Re: PTP packets not being acted upon by RHEL 7 server Another option, besides firewall, is Reverse Path filtering. Setting rp_filter to relaxed (=2) may help in some situations. regards Stan |
|
From: Dale S. <dal...@gm...> - 2016-12-16 00:37:56
|
On Thu, Dec 15, 2016 at 7:27 PM, Keller, Jacob E <jac...@in...> wrote: > > Additionally, check that wireshark and tcpdump are not running in promiscuous mode when you test. It is possible that you have a firewall (firewalld for example) disabling the packets, but when you run tcpdump in promiscuous mode it will be bypassing the firewall. This I believe is the default firewall settings for RHEL 7 so you should make sure you change that in firewalld to enable the traffic. Yep.. Something very similar happened to me before. mdns was just not working and when I fired up wireshark, it *magically* got fixed. I needed to all "allmulti" to the iface. Check the interface with either ifconfig or ip link and make sure MULTICAST is enabled.... -Dale |
|
From: Keller, J. E <jac...@in...> - 2016-12-16 00:30:43
|
> -----Original Message----- > From: Taber, Alan [mailto:ala...@lm...] > Sent: Thursday, December 15, 2016 12:07 PM > To: Richard Cochran <ric...@gm...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] EXTERNAL: Re: PTP packets not being acted upon by > RHEL 7 server > > Thanks, Richard. We're running IPv4 only. I'll check into Layer2 and report back. > > Since my previous email I've tried the same ptp4l -i enp9s0 -m on a second server > on the network, and it also is ignoring the other two asserting sources and > declaring itself as the master clock, and I see announce and sync packets from all > three sources on Wireshark. So there's something in the setup of the servers that > is preventing them from listening for those packets. > > Best regards, > Alan > Try running tcpdump without it setting the promiscuous flag. This smells suspiciously of a firewall issue, so maybe it's not the same thing you checked earlier? in RHEL 7 that should be firewalld but it might just iptables... What I suggest: run ptp4l and simultaneously run tcpdump but set the flag that prevents tcpdump from enabling promiscuous mode. If tcpdump still indicates that it sees packets but ptp4l does not then that is a different issue. You could also try running tcpdump in promicuous mode at the same time as ptp4l and see if that causes ptp4l to start seeing the packets. Thanks, Jake |
|
From: Keller, J. E <jac...@in...> - 2016-12-16 00:27:42
|
> -----Original Message----- > From: Richard Cochran [mailto:ric...@gm...] > Sent: Thursday, December 15, 2016 12:03 PM > To: Taber, Alan <ala...@lm...> > Cc: lin...@li... > Subject: Re: [Linuxptp-users] PTP packets not being acted upon by RHEL 7 server > > On Thu, Dec 15, 2016 at 06:18:33PM +0000, Taber, Alan wrote: > > I have a SecureSync 9400 GrandMaster clock that is appropriately putting out > PTPv2 Sync and Announce packets (verified by Wireshark listening on a different > network node). I have run tcpdump -i enp9s0 -v to check to see that the packets > are getting through to my RHEL 7 server, and they are showing up. > > > > Yet, when I run ptp4l -i enp9s0 -m, I get the following: > > Here ptp4l uses the default UDP/IPv4 transport. > > > What indicators should I be looking at to see why the local ptp daemon isn't > listening to the packets the server is receiving? > > Possibly the server is configured for Layer2 or IPv6? > > HTH, > Richard Additionally, check that wireshark and tcpdump are not running in promiscuous mode when you test. It is possible that you have a firewall (firewalld for example) disabling the packets, but when you run tcpdump in promiscuous mode it will be bypassing the firewall. This I believe is the default firewall settings for RHEL 7 so you should make sure you change that in firewalld to enable the traffic. Thanks, Jake |
|
From: Taber, A. <ala...@lm...> - 2016-12-15 22:09:01
|
Thanks, Richard. We're running IPv4 only. I'll check into Layer2 and report back. Since my previous email I've tried the same ptp4l -i enp9s0 -m on a second server on the network, and it also is ignoring the other two asserting sources and declaring itself as the master clock, and I see announce and sync packets from all three sources on Wireshark. So there's something in the setup of the servers that is preventing them from listening for those packets. Best regards, Alan -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: Thursday, December 15, 2016 2:03 PM To: Taber, Alan (US) <ala...@lm...> Cc: lin...@li... Subject: EXTERNAL: Re: [Linuxptp-users] PTP packets not being acted upon by RHEL 7 server On Thu, Dec 15, 2016 at 06:18:33PM +0000, Taber, Alan wrote: > I have a SecureSync 9400 GrandMaster clock that is appropriately putting out PTPv2 Sync and Announce packets (verified by Wireshark listening on a different network node). I have run tcpdump -i enp9s0 -v to check to see that the packets are getting through to my RHEL 7 server, and they are showing up. > > Yet, when I run ptp4l -i enp9s0 -m, I get the following: Here ptp4l uses the default UDP/IPv4 transport. > What indicators should I be looking at to see why the local ptp daemon isn't listening to the packets the server is receiving? Possibly the server is configured for Layer2 or IPv6? HTH, Richard |
|
From: Taber, A. <ala...@lm...> - 2016-12-15 20:52:20
|
Did check that - shows as installed but inactive, which is what I expected having disabled it via systemctl. Also tried using ptp4l -i enp9s0 -m -2, no change to the results. Best regards, Alan -----Original Message----- From: Richard Cochran [mailto:ric...@gm...] Sent: Thursday, December 15, 2016 2:50 PM To: Taber, Alan (US) <ala...@lm...> Cc: lin...@li... Subject: EXTERNAL: Re: EXTERNAL: Re: [Linuxptp-users] PTP packets not being acted upon by RHEL 7 server On Thu, Dec 15, 2016 at 08:06:38PM +0000, Taber, Alan wrote: > Thanks, Richard. We're running IPv4 only. I'll check into Layer2 and report back. > > Since my previous email I've tried the same ptp4l -i enp9s0 -m on a second server on the network, and it also is ignoring the other two asserting sources and declaring itself as the master clock, and I see announce and sync packets from all three sources on Wireshark. So there's something in the setup of the servers that is preventing them from listening for those packets. Firewall? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2016-12-15 20:50:16
|
On Thu, Dec 15, 2016 at 08:06:38PM +0000, Taber, Alan wrote: > Thanks, Richard. We're running IPv4 only. I'll check into Layer2 and report back. > > Since my previous email I've tried the same ptp4l -i enp9s0 -m on a second server on the network, and it also is ignoring the other two asserting sources and declaring itself as the master clock, and I see announce and sync packets from all three sources on Wireshark. So there's something in the setup of the servers that is preventing them from listening for those packets. Firewall? Thanks, Richard |
|
From: Richard C. <ric...@gm...> - 2016-12-15 20:02:52
|
On Thu, Dec 15, 2016 at 06:18:33PM +0000, Taber, Alan wrote: > I have a SecureSync 9400 GrandMaster clock that is appropriately putting out PTPv2 Sync and Announce packets (verified by Wireshark listening on a different network node). I have run tcpdump -i enp9s0 -v to check to see that the packets are getting through to my RHEL 7 server, and they are showing up. > > Yet, when I run ptp4l -i enp9s0 -m, I get the following: Here ptp4l uses the default UDP/IPv4 transport. > What indicators should I be looking at to see why the local ptp daemon isn't listening to the packets the server is receiving? Possibly the server is configured for Layer2 or IPv6? HTH, Richard |
|
From: Taber, A. <ala...@lm...> - 2016-12-15 18:20:16
|
I have a SecureSync 9400 GrandMaster clock that is appropriately putting out PTPv2 Sync and Announce packets (verified by Wireshark listening on a different network node). I have run tcpdump -i enp9s0 -v to check to see that the packets are getting through to my RHEL 7 server, and they are showing up. Yet, when I run ptp4l -i enp9s0 -m, I get the following: Selected /dev/ptp1 as PTP clock driver changed our HWTSTAMP options tx_type 1 not 1 rx_filter 1 not 12 port 1: INITIALIZING to LISTENING on INITIALIZE port 0: INITIALIZING to LISTENING on INITIALIZE port 1: link up port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES selected best master clock 0cc47a.fffe.acbaf7 at this point I can see sync and announce packets on the network from both my GrandMaster clock and this RHEL 7 server. What indicators should I be looking at to see why the local ptp daemon isn't listening to the packets the server is receiving? Thanks in advance for any insight you can share. Best regards, Alan Taber |
|
From: Dave B. <dav...@gm...> - 2016-11-23 18:38:11
|
On Tue, 22 Nov 2016 11:00:12 -0800, Richard Cochran wrote:
> PS IIRC, there is a technical hurdle to achieve real PHY time stamps
> in gigabit devices. Are you sure the Atheros time stamps in the PHY
> and not on the MII bus inputs/outputs? (Just curious)
I'm not sure I'm qualified to answer that question, but I'm including
the relevant figures and text excerpts that I found in the ar8031
datasheet below in case that helps.
Top Level Use of AR8031 in an IEEE 1588v2 system:
+-----------------+ +-------------+
| AR8031 | RGMII/ | Controller |
| +-------------+ | SGMII |-----+ |
Line | |1588v2 Module| |<-------->| | |
side | | +-----+ | | | MAC | |
<--->| | | RTC | | | | | |
| | +-----+ | |<-------->| | |
| +-------------+ | SMI |-----+ |
+-----------------+ +-------------+
A A |
| | V
1588 ref. Local PPS
clock 25MHz
(optional)
Top Level Diagram of the AR8031's IEEE 1588v2 module:
+---------------------------+
| 1588v2 Module |
Time of Day | +---------------------+ |
<--------------+--| IEEE 1588 Real | |
| | Time Clock | |
<--------------+--| | |
PPS | +---------------------+ |
| A |
| | |
| V |
MDC/MDIO | +---------------------+ |
<--------------+->| IEEE 1588 Control | |
| +---------------------+ |
| A |
| | |
| V |
| +---------------------+ |
RGMII/SGMII | | IEEE 1588 Timestamp | |
<--------------+->|Unit Packet Detection| |
| | and Processing | |
| +---------------------+ |
+---------------------------+
Block Diagram of the AR8031 1588v2 module:
Rx Tx
A | RGMII/SGMII
| |<------------->
| +++
| | | Tx FIFO
| +++
| |
| V
+----------+-----+
| . | | +-------------+
| . '-----+------->| |
| ..............|<-------| |
| miiswitch | | IEEE 1588v2 |
| ..............|------->| |
| . .----+<-------| |
| . | | | |
+-----------+----+ +-------------+
A |
| V
+----------------+
| |
| PCS |
| |
+----------------+
A |
| V
Rx Tx
Page 27 excerpt:
"On the transmit side, the PHY will monitor and parse the incoming packet
from the top layer, upon the request of sending IEEE 1588v2 packet, it
will calculate the accurate time of transmission onto the media and a
timestamp accordingly."
Page 28 excerpt:
"On the receive side, the PHY will monitor and parse the incoming packet
from media, and will generate a timestamp upon the reception of IEEE
1588v2 packets. The built-in parser is capable of detecting IEEE 1588v2
on ethernet layer 2 (including untagged, one VLAN tagged and two VLAN
tagged), or layer 3 IPv4/UDP, and IPv6/UDP (including PPPoE and SNAP)."
Thanks for your answers to my questions.
Dave
|
|
From: Richard C. <ric...@gm...> - 2016-11-22 18:58:16
|
On Tue, Nov 22, 2016 at 09:38:43AM -0800, Dave Berg wrote: > The system we're targeting is the TI am335x Starter Kit (TMDSSK3358), > which uses the Qualcomm Atheros ar8031 PHY, and the MAC in the am335x > processor uses the TI CPTS for timestamping. Just FYI, we don't have generic support for systems with both a MAC and a PHY PHC on the same interface. If and when you get a PHY driver, then you'll have to patch the MAC driver minimally to disable CPTS support and pass the ioctls through. > Is there any chance that a driver for the ar8031 with timestamping and > PHC support exists outside of mainline Linux so that we could still > potentially use this platform? Even an in-development driver could be > an option for us. I am not aware of any. > If not, is this group aware of any alternative 1 GigE PHYs with PHC > Linux driver support of some sort? Yeah, a gigabit PHY with PHC would be great, but unfortunately I have not seen one yet. Too bad NatSemi^W TI didn't produce a GB phyter. Sorry, Richard PS IIRC, there is a technical hurdle to achieve real PHY time stamps in gigabit devices. Are you sure the Atheros time stamps in the PHY and not on the MII bus inputs/outputs? (Just curious) |
|
From: Dave B. <dav...@gm...> - 2016-11-22 17:38:49
|
Hello, We have been using LinuxPTP with great success on a system with a dp83640 PHY and DaVinci MAC running Linux 4.2. We now need to move to a 1 GigE based system with PHY-based timestamping, but it seems that no driver exists which supports the PHC of the PHY we're targeting. The system we're targeting is the TI am335x Starter Kit (TMDSSK3358), which uses the Qualcomm Atheros ar8031 PHY, and the MAC in the am335x processor uses the TI CPTS for timestamping. I found a previous response from Richard on the linuxptp-devel mailing list (URL: https://sourceforge.net/p/linuxptp/mailman/message/31706496/) which states "Right now, the dp83640 is only PHY driver in the kernel with time stamping and PHC supported", but since that was written on 2013-12-02 I am hopeful that there may be more options by now. However, the mainline ar8031 PHY driver has no PHC support, and I see no other PHY-based timestamping solutions listed in the Driver Support Matrix in LinuxPTP's current readme file. Is there any chance that a driver for the ar8031 with timestamping and PHC support exists outside of mainline Linux so that we could still potentially use this platform? Even an in-development driver could be an option for us. If not, is this group aware of any alternative 1 GigE PHYs with PHC Linux driver support of some sort? Any help or suggestions would be greatly appreciated. Dave |
|
From: Hardik G. <har...@gm...> - 2016-11-22 08:28:59
|
Hello, How can get details on this ? I will be using HW time stamping at MAC layer at CPTS core for TI Chip. and linuxptp to synchronize clock between system clock and PTP hardware clock. Master clock is GPS receiver Regards, Hardik A Gohil On Tue, Nov 22, 2016 at 4:18 PM, Richard Cochran <ric...@gm...> wrote: > On Tue, Nov 22, 2016 at 02:21:07PM +0800, Hardik Gohil wrote: > > what is the accuracy of time sync ?? > > It depends. > > Cheers, > Richard > |
|
From: Richard C. <ric...@gm...> - 2016-11-22 08:18:53
|
On Tue, Nov 22, 2016 at 02:21:07PM +0800, Hardik Gohil wrote: > what is the accuracy of time sync ?? It depends. Cheers, Richard |
|
From: Hardik G. <har...@gm...> - 2016-11-22 06:21:14
|
Hello, Thank you. so for HW time stamping at CPTS core I need to change kernel to 3.8 or later. what is the accuracy of time sync ?? Regards, Hardik A Gohil On Tue, Nov 22, 2016 at 2:18 AM, Richard Cochran <ric...@gm...> wrote: > On Mon, Nov 21, 2016 at 10:13:32PM +0800, Hardik Gohil wrote: > > Does this means support is there from kernel 3.8 > > Yes. > > > Yes I have tried this method and posted the problem in previous message. > > You said you were running kernel 3.2. That won't work. Use kernel > 3.8 or later. > > BTW, the '-T' ethtool option only works on kernel 3.5 or later. > > HTH, > Richard > > |
|
From: Richard C. <ric...@gm...> - 2016-11-21 18:19:03
|
On Mon, Nov 21, 2016 at 10:13:32PM +0800, Hardik Gohil wrote: > Does this means support is there from kernel 3.8 Yes. > Yes I have tried this method and posted the problem in previous message. You said you were running kernel 3.2. That won't work. Use kernel 3.8 or later. BTW, the '-T' ethtool option only works on kernel 3.5 or later. HTH, Richard |
|
From: Hardik G. <har...@gm...> - 2016-11-21 14:13:44
|
On Nov 21, 2016 9:30 PM, "Richard Cochran" <ric...@gm...> wrote: > > On Mon, Nov 21, 2016 at 02:20:46PM +0800, Hardik Gohil wrote: > > starting from which kernel version support is there ? > > Check out the driver support matrix at: > > http://linuxptp.sourceforge.net > > There you will find: > > | cpts | Texas Instruments am335x | 3.8 | > Does this means support is there from kernel 3.8 > This information is also in the README.org file. > > > how to confirm HW time stamping feature ? > > ethtool -T is a good start. Yes I have tried this method and posted the problem in previous message. > > HTH, > Richard |
27 messages has been excluded from this view by a project administrator.
