From: Przemyslaw Korba <przemyslaw.korba@intel.com>
To: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, anthony.l.nguyen@intel.com,
przemyslaw.kitszel@intel.com, aleksandr.loktionov@intel.com,
arkadiusz.kubalewski@intel.com, konstantin.ilichev@intel.com
Subject: [PATCH iwl-net 0/4] ice: fix PTP timestamp handling issues
Date: Mon, 20 Jul 2026 14:01:28 +0200 [thread overview]
Message-ID: <20260720120151.2675206-1-przemyslaw.korba@intel.com> (raw)
This series fixes several PTP timestamp handling issues in the ice
driver that manifest during link state transitions on E82x devices.
Together, these issues can cause Tx timestamp timeouts, ptp4l service
disruptions, and on PREEMPT_RT kernels, a system livelock requiring a
hard reboot.
The root cause is a set of race conditions in the PTP link change path.
When taking the link down (ice_down) or bringing it up
(ice_up_complete), the PTP recalibration and cleanup were not properly
synchronized with actual physical link transitions. This allowed Tx
timestamp requests to be queued against uncalibrated or stopped PHY
hardware, producing orphaned timestamp ready bits in the PHY registers.
On E82x, the PHY will not generate a new timestamp interrupt until all
outstanding ready bits have been read. Orphaned bits — set for slots
with no matching software tracker entry — are never read, permanently
blocking new timestamp interrupts. The existing periodic work detects
this symptom and re-triggers the interrupt, but without clearing the
stale bits, this creates an infinite trigger loop. On PREEMPT_RT
kernels, the resulting interrupt storm causes RCU stalls and eventually
a full system livelock.
Arkadiusz Kubalewski (1):
ice: call PTP link change only from link events
Jacob Keller (1):
ice: clear unexpected Tx timestamp ready bits to prevent stuck PHY
Karol Kolacinski (2):
ice: keep Tx timestamps disabled until offset calibration completes
ice: cancel E82x offset verification work during reset preparation
drivers/net/ethernet/intel/ice/ice_main.c | 3 +-
drivers/net/ethernet/intel/ice/ice_ptp.c | 155 +++++++++++++++++---
drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 89 +++++++++--
drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 1 +
drivers/net/ethernet/intel/ice/ice_type.h | 7 +
5 files changed, 219 insertions(+), 36 deletions(-)
--
2.43.0
next reply other threads:[~2026-07-20 11:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 12:01 Przemyslaw Korba [this message]
2026-07-20 12:01 ` [PATCH iwl-net 1/4] ice: keep Tx timestamps disabled until offset calibration completes Przemyslaw Korba
2026-07-20 12:01 ` [PATCH iwl-net 2/4] ice: clear unexpected Tx timestamp ready bits to prevent stuck PHY Przemyslaw Korba
2026-07-23 8:26 ` [Intel-wired-lan] " Petr Oros
2026-07-23 13:15 ` Korba, Przemyslaw
2026-07-27 8:21 ` Korba, Przemyslaw
2026-07-27 22:46 ` Jacob Keller
2026-07-20 12:01 ` [PATCH iwl-net 3/4] ice: cancel E82x offset verification work during reset preparation Przemyslaw Korba
2026-07-20 12:01 ` [PATCH iwl-net 4/4] ice: call PTP link change only from link events Przemyslaw Korba
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=20260720120151.2675206-1-przemyslaw.korba@intel.com \
--to=przemyslaw.korba@intel.com \
--cc=aleksandr.loktionov@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=konstantin.ilichev@intel.com \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
/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