From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [DPDK/ethdev Bug 2100] net/ice: ice_get_module_eeprom() silently returns zeroed data when all I2C read retries fail
Date: Mon, 09 Nov 2026 15:43:09 +0000 [thread overview]
Message-ID: <bug-2100-3@https.bugs.dpdk.org/> (raw)
https://bugs.dpdk.org/show_bug.cgi?id=2100
Bug ID: 2100
Summary: net/ice: ice_get_module_eeprom() silently returns
zeroed data when all I2C read retries fail
Product: DPDK
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: ethdev
Assignee: dev@dpdk.org
Reporter: marcel@telka.sk
Target Milestone: ---
https://github.com/DPDK/dpdk/blob/a13c1053360ee26bbacca9f883d3f3cb83a0f366/drivers/net/intel/ice/ice_ethdev.c#L6742-L6767
for (j = 0; j < I2C_BUSY_TRY_TIMES; j++) {
status = ice_aq_sff_eeprom(hw, 0, addr, offset,
page, !is_sfp, value,
SFF_READ_BLOCK_SIZE,
0, NULL);
PMD_DRV_LOG(DEBUG, "SFF %02X %02X %02X %X = "
"%02X%02X%02X%02X."
"%02X%02X%02X%02X (%X)",
addr, offset, page, is_sfp,
value[0], value[1],
value[2], value[3],
value[4], value[5],
value[6], value[7],
status);
if (status) {
usleep_range(I2C_USLEEP_MIN_TIME,
I2C_USLEEP_MAX_TIME);
memset(value, 0, SFF_READ_BLOCK_SIZE);
continue;
}
break;
}
/* Make sure we have enough room for the new block */
if ((i + SFF_READ_BLOCK_SIZE) <= info->length)
memcpy(data + i, value, SFF_READ_BLOCK_SIZE);
Two separate problems in this retry loop's failure handling:
1. Zeroed data accepted as a successful read. status is never checked
after the loop exits. If all I2C_BUSY_TRY_TIMES (4) attempts fail, value
has been memset to zero by the last failed attempt, and that zeroed
block is still unconditionally copied into the output buffer as if
valid. The function falls through to return 0 (success) regardless.
A persistent I2C/admin-queue failure for any single 8-byte block -- the
comment directly above this code acknowledges I2C bus contention with
NIC link management is "normal" -- is therefore silently reported as a
successful read, with that block's bytes coming back all-zero,
indistinguishable from genuine zero-valued EEPROM content.
2. Debug log prints unread data as if it were the read result.
PMD_DRV_LOG fires unconditionally right after the ice_aq_sff_eeprom()
call, before the if (status) check and before the failure-path
memset(value, 0, ...). So on a failed attempt, the log line prints
value alongside the (correctly) failed status -- but value at that
point holds stale data: leftover from the previous block's last
successful read on a block's first failed attempt, or zeros from the
prior attempt's own memset on any subsequent retry of that same block.
Either way, it's never the result of the failed call being logged,
which can mislead debugging by making a failed read look like a
plausible real value.
Suggested fix:
bool block_ok = false;
for (j = 0; j < I2C_BUSY_TRY_TIMES; j++) {
status = ice_aq_sff_eeprom(...);
if (status) {
PMD_DRV_LOG(DEBUG, "SFF %02X %02X %02X %X read failed (%X)",
addr, offset, page, is_sfp, status);
usleep_range(...);
memset(value, 0, SFF_READ_BLOCK_SIZE);
continue;
}
PMD_DRV_LOG(DEBUG, "SFF %02X %02X %02X %X = "
"%02X%02X%02X%02X.%02X%02X%02X%02X",
addr, offset, page, is_sfp,
value[0], value[1], value[2], value[3],
value[4], value[5], value[6], value[7]);
block_ok = true;
break;
}
if (!block_ok)
return -EIO;
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2026-11-09 15:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=bug-2100-3@https.bugs.dpdk.org/ \
--to=bugzilla@dpdk.org \
--cc=dev@dpdk.org \
/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