Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
Hi Hagbin, I just back from holiday. Sorry I forgot to check the errno returned by ioctl. I saw Martin has send the fix for this issue. It would be good if you could check the fix does not break your use-case. Also, if you had any idea how to check for the VLAN over bond support without using SIOCGHWTSTAMP (which is only optional), it would be great. With the current patch, any NIC without SIOCGHWTSTAMP support will not report VLAN over bond support (but that was the case in your original patch before, too). Thanks, Martin smime.p7s Description: Elektronicky podpis S/MIME ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
Hi Richard, Martin, I just back from holiday. Sorry I forgot to check the errno returned by ioctl. I saw Martin has send the fix for this issue. Thanks Hangbin On Mon, May 01, 2023 at 09:08:30PM -0700, Richard Cochran wrote: > On Mon, May 01, 2023 at 06:29:59PM +0200, Martin Pecka wrote: > > > > A driver which supports hardware time stamping must support the > > > SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with > > > the actual values as described in the section on SIOCSHWTSTAMP. It > > > should also support SIOCGHWTSTAMP. > > The support for SIOCGHWTSTAMP is optional. > > > > So it seems to me wrong to test for the bonded PHC support using this ioctl, > > which is only optional. > > +1 > > > 1. Check errno not only for EINVAL, but also for EOPNOTSUPP. This would > > solve the issue for me (and Jetsons in general), but would probably leave > > some users with bonded PHCs whose drivers do not support SIOCGHWTSTAMP > > without the possibility to use the bonded PHC. > > +1 ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Mon, May 01, 2023 at 06:29:59PM +0200, Martin Pecka wrote: > > A driver which supports hardware time stamping must support the > > SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with > > the actual values as described in the section on SIOCSHWTSTAMP. It > > should also support SIOCGHWTSTAMP. > The support for SIOCGHWTSTAMP is optional. > > So it seems to me wrong to test for the bonded PHC support using this ioctl, > which is only optional. +1 > 1. Check errno not only for EINVAL, but also for EOPNOTSUPP. This would > solve the issue for me (and Jetsons in general), but would probably leave > some users with bonded PHCs whose drivers do not support SIOCGHWTSTAMP > without the possibility to use the bonded PHC. +1 Thanks, Richard ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
Did blame.
commit afeabf3c90edf6699d7e0d058593835ec258be46
Author: Hangbin Liu
Date: Wed May 25 14:46:16 2022 +0800
ptp4l: add VLAN over bond support
Perhaps Hangbin Liu can assist?
Erez
On Tue, 2 May 2023 at 00:08, Erez wrote:
>
>
> On Mon, 1 May 2023 at 18:30, Martin Pecka wrote:
>
>>
>> This code in hwts_init is wrong:
>>
>> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
>> /* Fall back without flag if user run new build on old kernel */
>> if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
>> init_ifreq(, , device);
>>
>> As `man ioctl` says:
>>
>> RETURN VALUE
>>Usually, on success zero is returned. A few ioctl() requests use
>> the
>>return value as an output parameter and return a nonnegative value
>> on
>>success. On error, -1 is returned, and errno is set appropriately.
>>
>> So I think what you meant to write is this:
>>
>> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
>> err = ioctl(fd, SIOCGHWTSTAMP, );
>> if (err < 0) {
>> /* Fall back without flag if user run new build on old kernel */
>> if (errno == EINVAL) {
>> init_ifreq(, , device);
>> } else {
>> pr_err("ioctl SIOCGHWTSTAMP failed: %m");
>> return err;
>> }
>> }
>>
>>
>> Agree. Applying this fix reveals the real error - EOPNOTSUPP.
>>
>> @Martin would that also fix your issue?
>>
>> No. Getting the real error code, I went after the source of EOPNOTSUPP,
>> and...
>>
>> $ sudo hwstamp_ctl -i eth0
>> Device driver does not have support for non-destructive SIOCGHWTSTAMP.
>>
>> This is it! The nvidia eqos driver does not support SIOCGHWTSTAMP (but it
>> does support SIOCSHWTSTAMP). Evidence can be found in
>> https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/drv.c#L3979
>> (function eqos_ioctl).
>>
>> According to
>> https://www.kernel.org/doc/Documentation/networking/timestamping.txt,
>> section 3.1:
>>
>> A driver which supports hardware time stamping must support the
>> SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
>> the actual values as described in the section on SIOCSHWTSTAMP. It
>> should also support SIOCGHWTSTAMP.
>>
>> The support for SIOCGHWTSTAMP is optional.
>>
>> So it seems to me wrong to test for the bonded PHC support using this
>> ioctl, which is only optional.
>>
>> To add importance to this issue, I've found out it not only affects the
>> pretty old Jetson TX2 I used for the test, but all Jetson models up to the
>> newest AGX Orin (included). Meaning no Jetson can run ptp4l from master
>> branch now. I really wonder I'm the first one complaining...
>>
>> Regarding possible solutions I can think of:
>>
>> 1. Check errno not only for EINVAL, but also for EOPNOTSUPP. This would
>> solve the issue for me (and Jetsons in general), but would probably leave
>> some users with bonded PHCs whose drivers do not support SIOCGHWTSTAMP
>> without the possibility to use the bonded PHC.
>>
>
> On a second review.
> I think you have a point.
>
> This get ioctl (SIOCGHWTSTAMP) was added for VLAN over bond support.
>
> On normal run, the get ioctl is only used with HWTS_FILTER_CHECK.
> So the user can switch to HWTS_FILTER_FULL or HWTS_FILTER_NORMAL and skip
> the get ioctl.
>
> But the get ioctl with bonded PHC index, can not be skipped.
>
>
>> 2. Find another way to test for the bonded PHC feature.
>>
> Perhaps a flag?
>
> Erez
>
>
>> Martin
>>
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Mon, 1 May 2023 at 18:30, Martin Pecka wrote:
>
> This code in hwts_init is wrong:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> /* Fall back without flag if user run new build on old kernel */
> if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
> init_ifreq(, , device);
>
> As `man ioctl` says:
>
> RETURN VALUE
>Usually, on success zero is returned. A few ioctl() requests use the
>return value as an output parameter and return a nonnegative value on
>success. On error, -1 is returned, and errno is set appropriately.
>
> So I think what you meant to write is this:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> err = ioctl(fd, SIOCGHWTSTAMP, );
> if (err < 0) {
> /* Fall back without flag if user run new build on old kernel */
> if (errno == EINVAL) {
> init_ifreq(, , device);
> } else {
> pr_err("ioctl SIOCGHWTSTAMP failed: %m");
> return err;
> }
> }
>
>
> Agree. Applying this fix reveals the real error - EOPNOTSUPP.
>
> @Martin would that also fix your issue?
>
> No. Getting the real error code, I went after the source of EOPNOTSUPP,
> and...
>
> $ sudo hwstamp_ctl -i eth0
> Device driver does not have support for non-destructive SIOCGHWTSTAMP.
>
> This is it! The nvidia eqos driver does not support SIOCGHWTSTAMP (but it
> does support SIOCSHWTSTAMP). Evidence can be found in
> https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/drv.c#L3979
> (function eqos_ioctl).
>
> According to
> https://www.kernel.org/doc/Documentation/networking/timestamping.txt,
> section 3.1:
>
> A driver which supports hardware time stamping must support the
> SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
> the actual values as described in the section on SIOCSHWTSTAMP. It
> should also support SIOCGHWTSTAMP.
>
> The support for SIOCGHWTSTAMP is optional.
>
> So it seems to me wrong to test for the bonded PHC support using this
> ioctl, which is only optional.
>
> To add importance to this issue, I've found out it not only affects the
> pretty old Jetson TX2 I used for the test, but all Jetson models up to the
> newest AGX Orin (included). Meaning no Jetson can run ptp4l from master
> branch now. I really wonder I'm the first one complaining...
>
> Regarding possible solutions I can think of:
>
> 1. Check errno not only for EINVAL, but also for EOPNOTSUPP. This would
> solve the issue for me (and Jetsons in general), but would probably leave
> some users with bonded PHCs whose drivers do not support SIOCGHWTSTAMP
> without the possibility to use the bonded PHC.
>
On a second review.
I think you have a point.
This get ioctl (SIOCGHWTSTAMP) was added for VLAN over bond support.
On normal run, the get ioctl is only used with HWTS_FILTER_CHECK.
So the user can switch to HWTS_FILTER_FULL or HWTS_FILTER_NORMAL and skip
the get ioctl.
But the get ioctl with bonded PHC index, can not be skipped.
> 2. Find another way to test for the bonded PHC feature.
>
Perhaps a flag?
Erez
> Martin
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
This code in hwts_init is wrong:
cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
/* Fall back without flag if user run new build on old kernel */
if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
init_ifreq(, , device);
As `man ioctl` says:
RETURN VALUE
Usually, on success zero is returned. A few ioctl() requests use the
return value as an output parameter and return a nonnegative value on
success. On error, -1 is returned, and errno is set appropriately.
So I think what you meant to write is this:
cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
err = ioctl(fd, SIOCGHWTSTAMP, );
if (err < 0) {
/* Fall back without flag if user run new build on old kernel */
if (errno == EINVAL) {
init_ifreq(, , device);
} else {
pr_err("ioctl SIOCGHWTSTAMP failed: %m");
return err;
}
}
Agree. Applying this fix reveals the real error - EOPNOTSUPP.
@Martin would that also fix your issue?
No. Getting the real error code, I went after the source of EOPNOTSUPP,
and...
$ sudo hwstamp_ctl -i eth0
Device driver does not have support for non-destructive SIOCGHWTSTAMP.
This is it! The nvidia eqos driver does not support SIOCGHWTSTAMP (but
it does support SIOCSHWTSTAMP). Evidence can be found in
https://github.com/OE4T/linux-tegra-4.9/blob/oe4t-patches-l4t-r32.7.3/nvidia/drivers/net/ethernet/nvidia/eqos/drv.c#L3979
(function eqos_ioctl).
According to
https://www.kernel.org/doc/Documentation/networking/timestamping.txt,
section 3.1:
A driver which supports hardware time stamping must support the
SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
the actual values as described in the section on SIOCSHWTSTAMP. It
should also support SIOCGHWTSTAMP.
The support for SIOCGHWTSTAMP is optional.
So it seems to me wrong to test for the bonded PHC support using this
ioctl, which is only optional.
To add importance to this issue, I've found out it not only affects the
pretty old Jetson TX2 I used for the test, but all Jetson models up to
the newest AGX Orin (included). Meaning no Jetson can run ptp4l from
master branch now. I really wonder I'm the first one complaining...
Regarding possible solutions I can think of:
1. Check errno not only for EINVAL, but also for EOPNOTSUPP. This would
solve the issue for me (and Jetsons in general), but would probably
leave some users with bonded PHCs whose drivers do not support
SIOCGHWTSTAMP without the possibility to use the bonded PHC.
2. Find another way to test for the bonded PHC feature.
Martin
smime.p7s
Description: Elektronicky podpis S/MIME
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Sun, 30 Apr 2023 at 23:26, Richard Cochran
wrote:
> On Thu, Mar 30, 2023 at 11:16:44AM +0800, Hangbin Liu wrote:
> > Richard, what do you think?
>
> This code in hwts_init is wrong:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> /* Fall back without flag if user run new build on old kernel */
> if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
> init_ifreq(, , device);
>
> As `man ioctl` says:
>
> RETURN VALUE
>Usually, on success zero is returned. A few ioctl() requests use
> the
>return value as an output parameter and return a nonnegative
> value on
>success. On error, -1 is returned, and errno is set appropriately.
>
> So I think what you meant to write is this:
>
> cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
> err = ioctl(fd, SIOCGHWTSTAMP, );
> if (err < 0) {
> /* Fall back without flag if user run new build on old
> kernel */
> if (errno == EINVAL) {
> init_ifreq(, , device);
> } else {
> pr_err("ioctl SIOCGHWTSTAMP failed: %m");
> return err;
> }
> }
>
> @Martin would that also fix your issue?
>
I support.
Erez
>
> Thanks,
> Richard
>
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Thu, Mar 30, 2023 at 11:16:44AM +0800, Hangbin Liu wrote:
> Richard, what do you think?
This code in hwts_init is wrong:
cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
/* Fall back without flag if user run new build on old kernel */
if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL)
init_ifreq(, , device);
As `man ioctl` says:
RETURN VALUE
Usually, on success zero is returned. A few ioctl() requests use the
return value as an output parameter and return a nonnegative value on
success. On error, -1 is returned, and errno is set appropriately.
So I think what you meant to write is this:
cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX;
err = ioctl(fd, SIOCGHWTSTAMP, );
if (err < 0) {
/* Fall back without flag if user run new build on old kernel */
if (errno == EINVAL) {
init_ifreq(, , device);
} else {
pr_err("ioctl SIOCGHWTSTAMP failed: %m");
return err;
}
}
@Martin would that also fix your issue?
Thanks,
Richard
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Thu, 30 Mar 2023 at 03:03, Martin Pecka 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, ) == -EINVAL) > init_ifreq(, , 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
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Thu, Mar 30, 2023 at 03:03:44AM +0200, Martin Pecka wrote: > 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, ) == -EINVAL) > init_ifreq(, , 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. Yes, this part is weird. I saw the eqos_ioctl -> eqos_handle_hwtstamp_ioctl() do return -EINVAL when there has config.flags. > 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 When I add this part, I made this checking strict to make sure it's a config flag error. If it's other errors, we don't need to remove the flag and do init_ifreq() again. I think we'd better find out why you got -1 return value instead of change the return value checking blindly. Richard, what do you think? Thanks Hangbin > 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. > > Thanks for your help, Erez. > > Martin > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
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, ) == -EINVAL) init_ifreq(, , 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. Thanks for your help, Erez. Martin smime.p7s Description: Elektronicky podpis S/MIME ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
Re: [Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
On Wed, 29 Mar 2023 at 11:27, Martin Pecka wrote: > Hello, > > I'm using linuxptp from master branch on a Jetson TX2 device, where > unfortunately only kernel 4.9.299 is available from the manufacturer. > commit 224d99f50f25ec3234b99556c0076a7130e230c6 (tag: v4.9.299) Author: Greg Kroah-Hartman Date: Sat Jan 29 10:15:58 2022 +0100 Linux 4.9.299 The kernel is 1 year and 3 month old, it should work. You mean this device: https://developer.nvidia.com/embedded/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. > > $ ethtool -T eth0 > Time stamping parameters for eth0: > Capabilities: > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) > software-system-clock (SOF_TIMESTAMPING_SOFTWARE) > hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE) > PTP Hardware Clock: 0 > Hardware Transmit Timestamp Modes: > off (HWTSTAMP_TX_OFF) > on(HWTSTAMP_TX_ON) > Hardware Receive Filter Modes: > none (HWTSTAMP_FILTER_NONE) > ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) > ptpv1-l4-delay-req(HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) > ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) > ptpv2-l4-delay-req(HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) > ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) > ptpv2-l2-delay-req(HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) > ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) > > After updating to v4.0, I've noticed ptp4l cannot run with hardware > timestamping: > linuxptp version 4 is not published yet, I assume you use the last master version, which you build yourself. > > $ sudo ptp4l -H -i eth0 -f /etc/linuxptp/automotive-slave.cfg -m -l6 > ptp4l[1045.377]: selected /dev/ptp0 as PTP clock > ptp4l[1045.420]: driver rejected most general HWTSTAMP filter > ptp4l[1045.421]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range > ptp4l[1045.456]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED > (FT_UNSPECIFIED) > > With the older version I used before (something after v3.1), it worked > flawlessly. > 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. > > Using git bisect, I've concluded that commit afeabf3 "ptp4l: add VLAN > over bond support" is the bad one. > > If I comment out this part in sk.c, I get HW timestamping working again > (line 67 onwards on current master): > Could be, then find the bug, please :-) Do you use VLANs or bonds? As the linuxptp should work the same without them. > > init_ifreq(, , device); > > //cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX; > /* Fall back without flag if user run new build on old kernel */ > //if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL) > // init_ifreq(, , device); > > What would be the best way to fix this properly? > If linuxptp has a bug, we should fix it. If the bug is in the 'eqos' driver, then the fix should be there. :-) Richard, do you think we should wait with commit afeabf3 "ptp4l: add VLAN over bond support"? Erez > Thanks, > > Martin > > ___ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel > ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
[Linuxptp-devel] Bug caused by commit afeabf3 "ptp4l: add VLAN over bond support" on kernel 4.9
Hello, I'm using linuxptp from master branch on a Jetson TX2 device, where unfortunately only kernel 4.9.299 is available from the manufacturer. The device's NIC uses eqos driver and reports all the timestamping capabilities required for ptp4l: $ ethtool -T eth0 Time stamping parameters for eth0: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC) ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ) ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC) ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ) ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC) ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ) ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT) After updating to v4.0, I've noticed ptp4l cannot run with hardware timestamping: $ sudo ptp4l -H -i eth0 -f /etc/linuxptp/automotive-slave.cfg -m -l6 ptp4l[1045.377]: selected /dev/ptp0 as PTP clock ptp4l[1045.420]: driver rejected most general HWTSTAMP filter ptp4l[1045.421]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range ptp4l[1045.456]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) With the older version I used before (something after v3.1), it worked flawlessly. Using git bisect, I've concluded that commit afeabf3 "ptp4l: add VLAN over bond support" is the bad one. If I comment out this part in sk.c, I get HW timestamping working again (line 67 onwards on current master): init_ifreq(, , device); //cfg.flags = HWTSTAMP_FLAG_BONDED_PHC_INDEX; /* Fall back without flag if user run new build on old kernel */ //if (ioctl(fd, SIOCGHWTSTAMP, ) == -EINVAL) // init_ifreq(, , device); What would be the best way to fix this properly? Thanks, Martin smime.p7s Description: Elektronicky podpis S/MIME ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
