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