netdev - Re: [EXTERNAL] net: atlantic: PHC time jumps ~4 seconds there and back on AQC107

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c6863fe5-a1f6-7bba-3f26-a1bda9141914@marvell.com>
Date: Tue, 6 Aug 2024 12:04:43 +0200
From: Igor Russkikh <irusskikh@...vell.com>
To: Martin Pecka <peckama2@....cvut.cz>
CC: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Dmitrii Bezrukov
	<dbezrukov@...vell.com>,
        Jackson Pooyappadam <jpooyappadam@...vell.com>
Subject: Re: [EXTERNAL] net: atlantic: PHC time jumps ~4 seconds there and
 back on AQC107


Hi Martin,

Sorry was on vacation so dropped out a bit.

On 7/21/2024 3:11 PM, Martin Pecka wrote:
> Thanks for the quick response, Igor.
> 
>> AQC107 is now in low maintenance mode in Marvell, and you are right this are of FW is not well documented.
> Off-topic: Interesting, given the number of devices out there using AQC107...
>> One suggestion. Have you tried playing with -R (slave update rate)? Increasing it?
> Tried it now and it seems it has no clear influence. I tested with -R 10 and -R 0.1 and in neither case were the time jumps more or less frequent.
>> I have a feeling the fact it happens periodically and then restores has something to do with "rounding" or NS calculations. Surprisingly uint32 fits 4 Billions of NS which is around 4 seconds...
> 
> I was also wondering whether the ~4B value could be some overflow. But the following investigation shows it is most probably not the case.

Thank you very much for the logs and the analysis.
I will try to investigate more with the data I have why this may happen.

The complex thing is that parts of ptp alignment calculations are happening in driver, and then some logic goes into the firmware/hardware.

Short term, I would say, your workaround with cutting negative mac_adj may have sense, until the real root cause is known.

Regards,
  Igor