We are just what is using what is there in the source code for phc2sys. the
code in question is in the sysoff.c file:
44 static int sysoff_precise(int fd, int64_t *result, uint64_t *ts)
45 {
46 struct ptp_sys_offset_precise pso;
47 memset(&pso, 0, sizeof(pso));
48 if (ioctl(fd, PTP_SYS_OFFSET_PRECISE, &pso)) {
49 print_ioctl_error("PTP_SYS_OFFSET_PRECISE");
50 return -errno;
51 }
52 *result = pctns(&pso.sys_realtime) - pctns(&pso.device);
53 *ts = pctns(&pso.sys_realtime);
54 return 0;
55 }
Could I get more clarification on my possible workaround? Are you saying
that once the timeout occurs the date and time are garbage forever?
tia,bernardo
On Thu, May 18, 2023 at 3:32 PM Jacob Keller <jacob.e.kel...@intel.com>
wrote:
>
>
> 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
