Hi Miroslav, Thank you very much for your great help
After debugging for a few days, I found that it was the ethernet driver that set PHC to SYS when processing ioctl. we modified the driver and the problem fixed. add some additional descriptions to this problem below: ptp4l slave config(--step_threshold=0.0, --max_frequency=1000000) before sync, slave_SYS(year 2000), master ts(year 2019) ptp4l slave side events: 0 process SYNC 1 send PDELAY_REQ 2 process FUP 3 sync PHC to master(set PHC to year 2019, but SYS is still year 2000) 3 clock.servo.state = JUMP 4 set PDELAY_REQ to NULL in port_synchronize() 5 process PDELAY_RESP(bc_event return -1) 6 set port.state = FAULTY 7 port.port_initialize()->transport_open()->raw_open()->sk_timestamping_init()->hwts_init()->*ioctl(fd, SIOCSHWTSTAMP)(eth driver set PHC to SYS(year 2000) in this ioctl)* 8 port processes other msgs after init, but servo transfer to LOCK state when next SYN/FUP come, PHC can only set max_frequency(1000000) Miroslav Lichvar <mlich...@redhat.com> 于2023年3月21日周二 15:56写道： > On Tue, Mar 21, 2023 at 10:17:56AM +0800, merlinhe wrote: > > 1. after the first clock jumpping, PHC jumpped to master, SYS keep the > > original value > > 2. peer_delay_req set to NUL > > 3. when the next peer_delay_resp arrives, the port enters the faulty > state, > > which cause the port reinited(PHC reset to SYS) > > By phc2sys? System clock shouldn't be used at all with HW > timestamping. > > > 4. then the next SYNC, FUP arrives, the clock.servo enter LOCK state, > > > > Do you have any suggestions to fix this problem? Or do I need to change > my > > ptp4l configuration? > > It's not very clear to me what is the issue that you are trying to > avoid. > > -- > Miroslav Lichvar > >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
