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] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250401-jk-igc-ptm-fixes-v4-v4-2-c0efb82bbf85@intel.com>
Date: Tue, 01 Apr 2025 16:35:30 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Anthony Nguyen <anthony.l.nguyen@...el.com>
Cc: david.zage@...el.com, vinicius.gomes@...el.com, 
 rodrigo.cadore@...coustics.com, intel-wired-lan@...ts.osuosl.org, 
 netdev@...r.kernel.org, Jacob Keller <jacob.e.keller@...el.com>, 
 Christopher S M Hall <christopher.s.hall@...el.com>, 
 Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>, 
 Mor Bar-Gabay <morx.bar.gabay@...el.com>, 
 Avigail Dahan <avigailx.dahan@...el.com>, 
 Corinna Vinschen <vinschen@...hat.com>
Subject: [PATCH iwl-net v4 2/6] igc: increase wait time before retrying PTM

From: Christopher S M Hall <christopher.s.hall@...el.com>

The i225/i226 hardware retries if it receives an inappropriate response
from the upstream device. If the device retries too quickly, the root
port does not respond.

The wait between attempts was reduced from 10us to 1us in commit
6b8aa753a9f9 ("igc: Decrease PTM short interval from 10 us to 1 us"), which
said:

  With the 10us interval, we were seeing PTM transactions take around
  12us. Hardware team suggested this interval could be lowered to 1us
  which was confirmed with PCIe sniffer. With the 1us interval, PTM
  dialogs took around 2us.

While a 1us short cycle time was thought to be theoretically sufficient, it
turns out in practice it is not quite long enough. It is unclear if the
problem is in the root port or an issue in i225/i226.

Increase the wait from 1us to 4us. Increasing to 2us appeared to work in
practice on the setups we have available. A value of 4us was chosen due to
the limited hardware available for testing, with a goal of ensuring we wait
long enough without overly penalizing the response time when unnecessary.

The issue can be reproduced with the following:

$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m

Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to
quickly reproduce the issue.

PHC2SYS exits with:

"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction
  fails

Fixes: 6b8aa753a9f9 ("igc: Decrease PTM short interval from 10 us to 1 us")
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
Tested-by: Mor Bar-Gabay <morx.bar.gabay@...el.com>
Tested-by: Avigail Dahan <avigailx.dahan@...el.com>
Signed-off-by: Christopher S M Hall <christopher.s.hall@...el.com>
Reviewed-by: Corinna Vinschen <vinschen@...hat.com>
Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
---
 drivers/net/ethernet/intel/igc/igc_defines.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igc/igc_defines.h b/drivers/net/ethernet/intel/igc/igc_defines.h
index 2ff292f5f63be29e42dc4491a56602d811cf22cc..d19325b0e6e0ba684abbe10482fecce92e405420 100644
--- a/drivers/net/ethernet/intel/igc/igc_defines.h
+++ b/drivers/net/ethernet/intel/igc/igc_defines.h
@@ -574,7 +574,10 @@
 #define IGC_PTM_CTRL_SHRT_CYC(usec)	(((usec) & 0x3f) << 2)
 #define IGC_PTM_CTRL_PTM_TO(usec)	(((usec) & 0xff) << 8)
 
-#define IGC_PTM_SHORT_CYC_DEFAULT	1   /* Default short cycle interval */
+/* A short cycle time of 1us theoretically should work, but appears to be too
+ * short in practice.
+ */
+#define IGC_PTM_SHORT_CYC_DEFAULT	4   /* Default short cycle interval */
 #define IGC_PTM_CYC_TIME_DEFAULT	5   /* Default PTM cycle time */
 #define IGC_PTM_TIMEOUT_DEFAULT		255 /* Default timeout for PTM errors */
 

-- 
2.48.1.397.gec9d649cc640


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ