Hi Vladimir,
Great help, thank you very much,
We will consider upgrading the kernel.
Vladimir Oltean 于2023年3月28日周二 15:04写道：
> On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote:
> > Richard Cochran 于2023年3月28日周二 11:27写道：
> > > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
>
On Tue, Mar 28, 2023 at 01:42:05PM +0800, Merlin He wrote:
> Richard Cochran 于2023年3月28日周二 11:27写道：
> > On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> > > Hi Miroslav,
> > >
> > > We use Synopsys's IP, the driver is the same as stmmac
> >
> > Yeah, the stmmac driver is crazy bad.
> >
Hi Richard,
Thank you, We are going to report this issue to Synopsys
Richard Cochran 于2023年3月28日周二 11:27写道：
> On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> > Hi Miroslav,
> >
> > We use Synopsys's IP, the driver is the same as stmmac
>
> Yeah, the stmmac driver is crazy bad.
>
>
On Tue, Mar 28, 2023 at 10:57:43AM +0800, merlinhe wrote:
> Hi Miroslav,
>
> We use Synopsys's IP, the driver is the same as stmmac
Yeah, the stmmac driver is crazy bad.
It is not clear to me whether setting the time when enabling time
stamping is actually required by the IP core or not.
But
Hi Miroslav,
We use Synopsys's IP, the driver is the same as stmmac
file: stmicro/stmmac/stmmac_main.c
function: static int stmmac_hwtstamp_set(struct net_device *dev, struct
ifreq *ifr)
692 /* initialize system time */
* 693 ktime_get_real_ts64();* 694
695 /* lower 32 bits of
On Fri, Mar 24, 2023 at 03:46:49PM +0800, merlinhe wrote:
>
> 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)*
That ioctl definitely shouldn't cause the PHC to be stepped.
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
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
Hi Miroslav,
Thank you very much for your clear explanation.
I now understand why peer_delay_req needed to be set to NULL when clock
jumping(to avoid the corruption of delay measurement)
But I have another problem now,
With ptp4l.max_frequency limited to 1,000,000(to avoid PHC big jumpping
On Wed, Mar 15, 2023 at 03:48:41PM +0800, merlinhe wrote:
> Hello Team,
>
> I recently encountered a *rogue peer delay response* error which seemly
> caused by function port_synchronize() reset peer_delay_req pointer.
> I'd like to know why port_synchronize() reset p->peer_delay_req to NULL is
>
Hello Team,
I recently encountered a *rogue peer delay response* error which seemly
caused by function port_synchronize() reset peer_delay_req pointer.
I'd like to know why port_synchronize() reset p->peer_delay_req to NULL is
needed, can i comment this to avoid the rogue peer delay response
11 matches
Mail list logo
