Re: mlx4_en SIOCSHWTSTAMP cycles the link

[Richard Cochran <richardcochran@gmail.com>]

On Mon, Dec 16, 2013 at 05:34:15PM -0600, Shawn Bohrer wrote:
> On Thu, Dec 12, 2013 at 09:28:15AM -0600, Shawn Bohrer wrote:
> > Below is v2.  It compiles, and boots, but linuxptp doesn't work yet
> > and I haven't looked into why.  I think linuxptp is actually
> > complaining about SIOCSHWTSTAMP not working as expected, but again I
> > haven't really even started debugging yet.
> 
> So performing a SIOCSHWTSTAMP on the mlx4_en driver cycles the link:
> 
> [ 9463.081330] mlx4_en: p2p1: Changing Time Stamp configuration
> [ 9463.084637] mlx4_en: p2p1:   frag:0 - size:1526 prefix:0 align:0 stride:1536
> [ 9463.155533] mlx4_en: p2p1: Link Down
> [ 9466.471169] mlx4_en: p2p1: Link Up
> 
> This breaks linuxptp (ptp4l) since it causes all of the already open
> sockets to silently loose their multicast joins.  Thus ptp4l sits
> there waiting for multicast PTP packets that aren't going to come.

The ptp4l program should notice this and recover. This happens when
catching the transmission error on the next sync or delay request. (Or
in slave only E2E mode the sockets are closed and reopened after every
announce interval). If this isn't happening, please post to the
linuxptp-users list the details of your setup.

> I hacked around this in ptp4l by performing the ioctl once with the
> hwstamp_ctl program from linuxptp and skipping the ioctl in ptp4l,
> which works, but quite frankly this sucks.  I'd love to know if anyone
> has any better ideas on how to make SIOCSHWTSTAMP usable.
> 
> After hacking around the SIOCSHWTSTAMP issue I've noticed that ptp4l
> synchronizes the PHC, however there must be another bug somewhere
> because it creates a 35 second offset from the PTP master.

This is the current TAI-UTC offset. Maybe your grand master is serving
UTC instead of the PTP timescale?

Thanks,
Richard