On Wed, 24 Jun 2020 at 21:22, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Wed, Jun 24, 2020 at 09:16:42PM +0300, Vladimir Oltean wrote: > > Treating it as an event on a data queue is a bug. > > Yeah, I guess we have just been lucky all this time.
I can sense some irony here, but I don't see your point though? I mean, take any board which has a DSA master that supports PTP timestamping and a DSA switch that also supports PTP timestamping, and run that "tcpdump -j adapter_unsynced" command on the DSA master. If you don't have my patch that prevents that from happening: https://patchwork.ozlabs.org/project/netdev/patch/20191228133046.9406-3-olte...@gmail.com/ then what'll happen is exactly what happened to me. Although in my case it was due to a driver bug, and in the tcpdump case it is due to a systematic limitation of the SO_TIMESTAMPING API. Not only that, but when you're coming from the angle that "tcpdump broke ptp4l", then you at least have some sort of rope to cling on to (if you want to, that is). And I _guarantee_ to you that somebody out there ran into that oddity at least once before, said "huh, weird, what a buggy system" and went on with their life. So, not really worth it to investigate, when there's something you can do to avoid the problem. But just blowing off the fact that it _is_ easy to reproduce even without "odd" driver bugs is pushing it a bit, IMO. So, I guess we _have_ been lucky all this time, in the "ignorance is bliss" sense. The ptp4l program does the same thing in both cases, and it isn't something that is correct given its options. Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
