Re: [Linuxptp-users] phc2sys exists with a Connection Timed Out error

[Jacob K. <jac...@in...>]

On 5/18/2023 3:16 PM, Bernie Elayda wrote:
> And more detail on the Ethernet driver used on our NUC(duplicating previous
> info for completeness, too)
> 
>  Ubutnu 18.04 with kernel 5.4.0-generic
> System-manufacturer :  Intel(R) Client Systems
> System-product-name :  NUC10i7FNH
> Bios-release-date :  04/09/2021
> Bios-version :  FNCML357.0052.2021.0409.1144
> 
> 00:1f.6 Ethernet controller: Intel Corporation Device 0d4f
>         Subsystem: Intel Corporation Device 2081
>         Flags: bus master, fast devsel, latency 0, IRQ 149
>         Memory at 96300000 (32-bit, non-prefetchable) [size=128K]
>         Capabilities: [c8] Power Management version 3
>         Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Kernel driver in use: e1000e
>         Kernel modules: e1000e
> 
> 

Thanks,

A quick search indicates this appears to be an e1000e-based controller
by the presence of this define in e1000e/hw.h on a current Linux kernel:

#define E1000_DEV_ID_PCH_CMP_I219_V10>-->-------0x0D4F

At least on mainline kernels I could check, the e1000e_phc_gettimex
function does not have a failure condition

You're using PTP_SYS_OFFSET_PRECISE ioctl to get the clock time?

The implementation in e1000e_phc_get_syncdevicetime does have a timeout
condition if it is unable to acquire the timestamp within a delay.

Unfortunately I am unfamiliar with this hardware so I do not know what
the delay value is or whether it would be safe to change it.

It is likely you occasionally hit the delay and timeout.

I do not think your suggested modification of the SYS_OFFSET_PRECISE
ioctl is a valid solution since I would expect that accepting the last
value would be accepting some garbage data and be incorrect....