Bug#1036744: PTP in combination with vclocks partially broken on Debian kernels
Control: tags -1 + moreinfo
On Thu, May 25, 2023 at 07:21:41AM +0000, Bezdeka, Florian wrote:
> Package: linux-image-amd64
> Version: 6.1.27-1
>
> Hi all,
>
> we did some investigations regarding time synchronization on Debian.
> Background is industrial communication on Linux in general.
>
> We found out that the PTP subsystem is only partially usable in
> combination with virtual clocks on Debian. While the setup was running
> fine on other distributions (like Ubuntu and Fedora) we had problems to
> bring it up and running on Debian.
>
> When starting ptp4l in combination with a vclock, the vclock could be
> created but not attached to a physical clock:
>
> ptp4l[127.805]: selected /dev/ptp4 as PTP clock
> ptp4l[127.805]: port 1 (enptp): PHC device mismatch
> ptp4l[127.805]: port 1 (enptp): /dev/ptp4 requested, ptp0 attached
> ptp4l[127.805]: failed to open port enptp
> failed to create a clock
>
> It turned out that CONFIG_PTP_1588_CLOCK makes the difference. When
> enabled (built-in, =y) our setup works, when set to "m" we run into
> problems. The "problematic" code can be found at [1].
>
> Might I request to set CONFIG_PTP_1588_CLOCK to y in the Debian kernel
> configuration?
Question: Is this a bug, why does the code needs to expect it to be
builtin? (I'm not meaning what is present actually in the code, but
why it *needs* to be builtin on upstream side)? AFAICS the requirement
is added with e5f31552674e ("ethernet: fix PTP_1588_CLOCK
dependencies") in 5.15-rc1. As explained in the commit in the
following:
| However, the two recently added ptp_get_vclocks_index() and
| ptp_convert_timestamp() interfaces are only called from builtin code with
| ethtool and socket timestamps, so keep the current behavior by stubbing
| those out completely when PTP is in a loadable module. This should be
| addressed properly in a follow-up.
|
| As Richard suggested, we may want to actually turn PTP support into a
| 'bool' option later on, preventing it from being a loadable module
| altogether, which would be one way to solve the problem with the ethtool
| interface.
Ben, would you agree on make the PTP support.
> It would be possible that we provide a merge request on
> salsa.debian.org. Just tell me the correct target branch. We would be
> very happy to have it in 6.1 (bookworm) and of course in all kernel
> flavors/feature sets.
I do not plan do accept any further bookworm targetting updates *right
now*, mabye later for bookworm point releases as we are now in full
freeze. There is no further upload planned for the 6.1.y series to
unstable, following to be migrated in testing before the bookworm
release. We can first apply to master and experimental upload if
agreed on the following change above and then consider it later for
bookworm.
Hope this helps already
Regards,
Salvatore
Reply to: