From: George Neville-N. <gn...@ne...> - 2011-12-09 21:55:35
|
On Dec 8, 2011, at 16:20 , Moschowits, Avi wrote: > Folks, > > I have been using PTP_V2 (think it’s probably release 87), for quite a while. I have recently run into an issue, & was looking at later code in Source-Forge as well as head release 153, and came across the release of v2-branch 142, I tried to compile both and run the branch/v2 code. I’m running on Linux-RH5 2.6.18-128.1.6.el5. > > Previously I run my clients with the following command options: > > ptpd2 -b eth? -i 0 -T 2 -h -m 6 -f … /ptpd2.log -D -g -x -O 500000000 > > Trying the same options with the latest release I get the following errors > # Timestamp, State, Clock ID, One Way Delay, Offset from Master, Slave to Master, Master to Slave, Drift, Last packet Received > 2011-12-01 17:15:26.940988, init > 2011-12-01 17:15:26.973823, flt > > In order to get more verbose output, I have added the debug version and get this > ptpd2_v2_debug -b eth? -C -i 0 -T 2 -h -m 6 -D -g -x -O 500000000 > > (ptpd info) 17:18:48.421136 (___) Info: Going to check lock /var/run/kernel_clock > (ptpd info) 17:18:48.430447 (___) Info: No ptpd daemons detected in parallel (as expected) > (ptpd info) 17:18:48.440054 (___) Info: No ntpd daemons detected in parallel (as expected) > (ptpd info) 17:18:48.440181 (___) Info: Going to check lock /var/run/kernel_clock > (ptpd info) 17:18:48.440382 (___) Info: Startup finished sucessfully > # Timestamp, State, Clock ID, One Way Delay, Offset From Master, Slave to Master, Master to Slave, Drift, Last packet Received > 2011-12-01 17:18:48.440524, init > (ptpd error) 17:18:48.467829 (init) failed to enable receive time stamps (ptpd error) 17:18:48.467963 (init) failed to initialize network > 2011-12-01 17:18:48.468046, flt > (ptpd notice) 17:18:48.495316 (flt) self shutdown, probably due to an error > > I then took a step back, and try and figure out which is the latest branch of V2 that still works for me. It seems release 135 is the latest release that does not suffer from above issue. Can you help me understand what the issue is? Or suggest what to do next? > > This looks like a conflict with the SO_TIMESTAMPNS support that was added and is now in the HEAD of the v2 branch. Can you make sure your kernel has support for that option? Also, could you build the daemon with DEBUG turned on so that we can get a few more messages? That will let us know specifically what's failing. Best, George |