On Thu, 30 Mar 2023 at 03:03, Martin Pecka <pecka...@fel.cvut.cz> wrote:
> > > The kernel is 1 year and 3 month old, it should work. > > You mean this device: https://developer.nvidia.com/embedded/jetson-tx2 > Yes. NVidia Jetson TX2. > > > > > > The device's NIC uses eqos driver and reports all the timestamping > > capabilities required for ptp4l: > > > > > > I do not find any 'eqos' driver in kernel 4.9.299. > > It is probably a private driver. Please ask your manufacturer for a > > full source code of the kernel. > > As it is a GPL 2 software, he should. > It can be found here: > > https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/ethtool.c#L276 > . It seems to be a driver written directly by NVidia for their custom > NIC contained in the SoC. > > linuxptp version 4 is not published yet, I assume you use the last > > master version, which you build yourself. > I am compiling master branch myself. > > Do you use VLANs or bonds? > No. > > > > ptp4l[1045.420]: driver rejected most general HWTSTAMP filter > > ptp4l[1045.421]: ioctl SIOCSHWTSTAMP failed: Numerical result out > > of range > > > > > > I remember we did some upgrades regarding very old kernels, > > yet Linux 4.9 should work. > > However as the 'eqos' driver is private, the problem might be there. > > I have a suspicion regarding the code in sk.c: > > ```c++ > cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX; > /* Fall back without flag if user run new build on old kernel */ > if (ioctl(fd, SIOCGHWTSTAMP, &ifreq) == -EINVAL) > init_ifreq(&ifreq, &cfg, device); > ``` > > The eqos driver returns EINVAL if any flag is set in the ioctl handler: > > https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/drv.c#L3760 > . > > However, the ioctl call has result -1, which is not -EINVAL, but -EPERM. > There is no EPERM in the ioctl handler code. So I'm not sure what > mechanism kicks in that either doesn't even let the ioctl bubble to the > driver, or that changes the return code. The consequence is that the > fallback code is not called and thus the following ioctls try to first > get PTP_V2_EVENT timestamping with the bond flag (timestamping mode is > supported, but bonding is not), and then tries the rx_filter2, which is > in this case PTP_V2_L2_EVENT (which is not supported by the driver). > > Anyways, the fix for me would be checking the ioctl result also for > -EPERM instead of just -EINVAL. Or, would there be any downside to just > testing if the ioctl result is negative? I've tested the code with this > fix and it works for me. I have no idea about how it could or could not > influence bonds. > $ errno EINVAL EINVAL 22 Invalid argument $ errno EPERM EPERM 1 Operation not permitted The EINVAL error in the driver means that the configuration sent with the ioctl is not accepted by the driver. The configuration should match the capabilities you fetch with "ethtool -T eth0", as you mentioned. This EPERM error does not exist in the driver ioctl callback for a good reason. It is returned by the kernel network layer. Looking at kernel net source code https://elixir.bootlin.com/linux/v4.9.299/source/net For example in core/dev_ioctl.c It is usually returned for: ```c++ if (!capable(CAP_NET_ADMIN)) return -EPERM; ``` Or with network namespace ```c++ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) return -EPERM; ``` I do not think we want to check this error in sk.c. Unless the error was generated by something more reasonable. Erez > > Thanks for your help, Erez. > > Martin > >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
