linux icon indicating copy to clipboard operation
linux copied to clipboard

ptp4l fails to start if started by systemd

Open dsseng opened this issue 1 year ago • 3 comments

Describe the bug

If I configure systemd to start ptp4l as a service, it fails like this

Jan 22 15:04:20 helios ptp4l[705]: [6.458] driver rejected most general HWTSTAMP filter
Jan 22 15:04:20 helios ptp4l[705]: [6.458] ioctl SIOCSHWTSTAMP failed: Invalid argument

That's most likely caused by the fact these lines follow the ptp4l error:

[    7.461099] macb 1f00100000.ethernet eth0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL)
[    7.461107] macb 1f00100000.ethernet eth0: configuring for phy/rgmii-id link mode
[    7.463644] pps pps0: new PPS source ptp0
[    7.463724] macb 1f00100000.ethernet: gem-ptp-timer ptp clock registered.

Steps to reproduce the behaviour

  1. Install ptp4l either from Debian packages or from source, both exhibit the same bug.
  2. systemctl enable [email protected]
  3. Reboot
  4. systemctl status [email protected] - error
  5. systemctl restart [email protected]
  6. systemctl enable [email protected] - fine

Device (s)

Raspberry Pi 5

System

Raspberry Pi reference 2023-12-11
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 2acf7afcba7d11500313a7b93bb55a2aae20b2d6, stage2

2024/01/15 19:02:28 
Copyright (c) 2012 Broadcom
version f0aa0715 (release) (embedded)

Linux helios 6.1.0-rpi7-rpi-2712 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux

Logs

No response

Additional context

Perhaps this is caused by probe order or internal dependencies. However macb module seems to be built-in in Pi 5 kernel.

Adding dev-ptp0 to After for the ptp4l service doesn't help, it still gets initialized before PTP clock is fully set up. If this cannot be fixed I'd appreciate at least a suggestion how do I make ptp4l start after things are properly initialized without hacks like starting it after some time.

dsseng avatar Jan 22 '24 12:01 dsseng

I can confirm this issue also with the latest 6.9 kernel and the latest linuxptp.

by avatar May 08 '24 15:05 by

Some more checking revealed that this appears to be a timing issue with eth0 and its drivers not ready in a timely manner after reboot: if one disables ptp4l (and phc2sys, just in case) and restarts the machine, then waiting a couple of minutes, the service runs without any problems.

by avatar May 09 '24 10:05 by