From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Bob Van Valzah <bob@vanvalzah.com>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>
Cc: intel-wired-lan@lists.osuosl.org, anthony.l.nguyen@intel.com,
netdev@vger.kernel.org, julianstj@fb.com, jeff@jeffgeerling.com,
Lasse Johnsen <lasse@timebeat.app>, Ian Gough <ian@timebeat.app>
Subject: Re: [Intel-wired-lan] [PATCH] igc: fix Tx timestamp timeout caused by unlocked TIMINCA write in adj fine]
Date: Thu, 02 Apr 2026 16:48:35 -0700 [thread overview]
Message-ID: <874ilsyld8.fsf@intel.com> (raw)
In-Reply-To: <CDC20B85-E83B-4AC9-9261-24B3D967DCA6@vanvalzah.com>
Hi,
Bob Van Valzah <bob@vanvalzah.com> writes:
> Vadim,
>
> Thanks for the feedback on our first patch. We've spent more time in
> the lab studying the igc TX timestamp behavior under stress. We
> understand the failure modes much better now.
>
> You were right that ptp_tx_lock was the wrong lock — it guards the TX
> queue, not the timing registers. You suggested tmreg_lock instead. We
> tested tmreg_lock alone (v2) and found it doesn't fix the bug: it appears
> that the race is between the software TIMINCA write and the hardware’s
> asynchronous TX timestamp capture pipeline, not between two software threads.
> tmreg_lock serializes software register accesses but can't prevent the hardware
> from reading TIMINCA at the instant software writes it.
>
> Our v3 patch (attached) takes tmreg_lock as you suggested, and
> additionally disables TX timestamping in hardware via TSYNCTXCTL around
> the TIMINCA write. This prevents the hardware from starting new
> timestamp captures during the rate change:
>
> spin_lock_irqsave(&igc->tmreg_lock, flags);
> txctl = rd32(IGC_TSYNCTXCTL);
> wr32(IGC_TSYNCTXCTL, txctl & ~IGC_TSYNCTXCTL_ENABLED);
> wr32(IGC_TIMINCA, inca);
> wr32(IGC_TSYNCTXCTL, txctl);
> spin_unlock_irqrestore(&igc->tmreg_lock, flags);
>
I sent, a couple of days ago, the link to your report to our hardware
folks, waiting for them to take a look.
I think that this workaround, even if incomplete, will be interesting to
them as well. Again, thanks for the detailed report.
Cheers,
--
Vinicius
prev parent reply other threads:[~2026-04-02 23:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-29 3:25 [PATCH] igc: fix Tx timestamp timeout caused by unlocked TIMINCA write in adj fine Bob Van Valzah
2026-03-30 16:39 ` Vadim Fedorenko
2026-03-30 19:42 ` Bob Van Valzah
2026-04-01 1:14 ` Bob Van Valzah
2026-04-02 0:49 ` [PATCH] igc: fix Tx timestamp timeout caused by unlocked TIMINCA write in adj fine] Bob Van Valzah
2026-04-02 23:48 ` Vinicius Costa Gomes [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874ilsyld8.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=bob@vanvalzah.com \
--cc=ian@timebeat.app \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeff@jeffgeerling.com \
--cc=julianstj@fb.com \
--cc=lasse@timebeat.app \
--cc=netdev@vger.kernel.org \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox