* [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
@ 2025-04-22 7:43 Jacek Kowalski
2025-04-22 8:39 ` [Intel-wired-lan] " Lifshits, Vitaly
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Jacek Kowalski @ 2025-04-22 7:43 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
Some Dell Tiger Lake systems have incorrect NVM checksum. These also
have a bitmask that indicates correct checksum set to "invalid".
Because it is impossible to determine whether the NVM write would finish
correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
it makes sense to skip the validation completely under these conditions.
Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
Cc: stable@vger.kernel.org
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 364378133526..df4e7d781cb1 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -4274,6 +4274,8 @@ static s32 e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
ret_val = e1000e_update_nvm_checksum(hw);
if (ret_val)
return ret_val;
+ } else if (hw->mac.type == e1000_pch_tgp) {
+ return 0;
}
}
--
2.39.5
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-22 7:43 [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set Jacek Kowalski
@ 2025-04-22 8:39 ` Lifshits, Vitaly
2025-04-24 16:24 ` Simon Horman
2025-05-12 17:25 ` Vlad URSU
2 siblings, 0 replies; 19+ messages in thread
From: Lifshits, Vitaly @ 2025-04-22 8:39 UTC (permalink / raw)
To: Jacek Kowalski, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
On 4/22/2025 10:43 AM, Jacek Kowalski wrote:
> Some Dell Tiger Lake systems have incorrect NVM checksum. These also
> have a bitmask that indicates correct checksum set to "invalid".
>
> Because it is impossible to determine whether the NVM write would finish
> correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
> it makes sense to skip the validation completely under these conditions.
>
> Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
> Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM
> checksum")
> Cc: stable@vger.kernel.org
> ---
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> index 364378133526..df4e7d781cb1 100644
> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> @@ -4274,6 +4274,8 @@ static s32
> e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
> ret_val = e1000e_update_nvm_checksum(hw);
> if (ret_val)
> return ret_val;
> + } else if (hw->mac.type == e1000_pch_tgp) {
> + return 0;
> }
> }
>
Thanks, looks good to me.
Reviewed-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-22 7:43 [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set Jacek Kowalski
2025-04-22 8:39 ` [Intel-wired-lan] " Lifshits, Vitaly
@ 2025-04-24 16:24 ` Simon Horman
2025-04-24 16:46 ` Jacek Kowalski
2025-04-24 16:59 ` [Intel-wired-lan] " Lifshits, Vitaly
2025-05-12 17:25 ` Vlad URSU
2 siblings, 2 replies; 19+ messages in thread
From: Simon Horman @ 2025-04-24 16:24 UTC (permalink / raw)
To: Jacek Kowalski
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
On Tue, Apr 22, 2025 at 09:43:01AM +0200, Jacek Kowalski wrote:
> Some Dell Tiger Lake systems have incorrect NVM checksum. These also
> have a bitmask that indicates correct checksum set to "invalid".
>
> Because it is impossible to determine whether the NVM write would finish
> correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
> it makes sense to skip the validation completely under these conditions.
>
> Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
> Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
I think that while the commit cited above relates to this problem,
this bug actually dates back to the patch I'm citing immediately below.
And I think we should cite that commit here. IOW, I'm suggesting:
Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake")
> Cc: stable@vger.kernel.org
That not withstanding, based on the commit message,
and the use of e1000_pch_tgp in another Tiger Lake fix [1],
I think this patch looks good.
Reviewed-by: Simon Horman <horms@kernel.org>
[1] commit ffd24fa2fcc7 ("e1000e: Correct NVM checksum verification flow")
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-24 16:24 ` Simon Horman
@ 2025-04-24 16:46 ` Jacek Kowalski
2025-04-24 17:18 ` Simon Horman
2025-04-24 16:59 ` [Intel-wired-lan] " Lifshits, Vitaly
1 sibling, 1 reply; 19+ messages in thread
From: Jacek Kowalski @ 2025-04-24 16:46 UTC (permalink / raw)
To: Simon Horman
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
>> Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM
>> checksum")
>
> I think that while the commit cited above relates to this problem,
> this bug actually dates back to the patch I'm citing immediately
> below. And I think we should cite that commit here. IOW, I'm
> suggesting:
>
> Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake")
I had my doubts when choosing a commit for the "Fixes" tag, but since
my setup would most likely work up until 4051f68318ca9, I selected it
specifically.
On my laptop NVM write attempt does (temporarily) fix a checksum
and makes driver loading possible. Only after 4051f68318ca9, which
disabled this code path (because it broke someone else's setup), I'd
be unable to use my network adapter anymore.
--
Best regards,
Jacek Kowalski
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-24 16:46 ` Jacek Kowalski
@ 2025-04-24 17:18 ` Simon Horman
2025-04-24 17:37 ` Jacek Kowalski
0 siblings, 1 reply; 19+ messages in thread
From: Simon Horman @ 2025-04-24 17:18 UTC (permalink / raw)
To: Jacek Kowalski
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
On Thu, Apr 24, 2025 at 06:46:45PM +0200, Jacek Kowalski wrote:
> > > Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM
> > > checksum")
> >
> > I think that while the commit cited above relates to this problem, this
> > bug actually dates back to the patch I'm citing immediately below. And I
> > think we should cite that commit here. IOW, I'm suggesting:
> >
> > Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake")
>
> I had my doubts when choosing a commit for the "Fixes" tag, but since
> my setup would most likely work up until 4051f68318ca9, I selected it
> specifically.
>
> On my laptop NVM write attempt does (temporarily) fix a checksum
> and makes driver loading possible. Only after 4051f68318ca9, which
> disabled this code path (because it broke someone else's setup), I'd
> be unable to use my network adapter anymore.
Thanks, in that case things aren't as clear as I had assumed
when writing my previous email.
If the problem only occurs after 4051f68318ca9 then I think
it is fine to use that commit in the Fixes tag.
Although I do wonder if commit 4051f68318ca9 is backported,
will this patch (once accepted) end up being backported far enough?
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-24 17:18 ` Simon Horman
@ 2025-04-24 17:37 ` Jacek Kowalski
2025-04-25 16:45 ` Simon Horman
0 siblings, 1 reply; 19+ messages in thread
From: Jacek Kowalski @ 2025-04-24 17:37 UTC (permalink / raw)
To: Simon Horman
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
> Although I do wonder if commit 4051f68318ca9 is backported,
> will this patch (once accepted) end up being backported far enough?
Stable 5.10 (and newer) already has 4051f68318ca9 and ffd24fa2fcc7:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/intel/e1000e/ich8lan.c?h=linux-5.10.y#n4139
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/ethernet/intel/e1000e/ich8lan.c?h=linux-5.10.y&id=8f1e3ad9456935f538c4ba06d2c04f2581ec385f
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/ethernet/intel/e1000e/ich8lan.c?h=linux-5.10.y&id=eb5e444fe37d467e54d2945c1293f311ce782f67
In my opinion my patch should be backported as well.
--
Best regards,
Jacek Kowalski
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-24 17:37 ` Jacek Kowalski
@ 2025-04-25 16:45 ` Simon Horman
0 siblings, 0 replies; 19+ messages in thread
From: Simon Horman @ 2025-04-25 16:45 UTC (permalink / raw)
To: Jacek Kowalski
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
On Thu, Apr 24, 2025 at 07:37:26PM +0200, Jacek Kowalski wrote:
> > Although I do wonder if commit 4051f68318ca9 is backported,
> > will this patch (once accepted) end up being backported far enough?
>
> Stable 5.10 (and newer) already has 4051f68318ca9 and ffd24fa2fcc7:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/intel/e1000e/ich8lan.c?h=linux-5.10.y#n4139
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/ethernet/intel/e1000e/ich8lan.c?h=linux-5.10.y&id=8f1e3ad9456935f538c4ba06d2c04f2581ec385f
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/net/ethernet/intel/e1000e/ich8lan.c?h=linux-5.10.y&id=eb5e444fe37d467e54d2945c1293f311ce782f67
>
> In my opinion my patch should be backported as well.
Yes, I agree.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-24 16:24 ` Simon Horman
2025-04-24 16:46 ` Jacek Kowalski
@ 2025-04-24 16:59 ` Lifshits, Vitaly
2025-04-24 17:29 ` Jacek Kowalski
1 sibling, 1 reply; 19+ messages in thread
From: Lifshits, Vitaly @ 2025-04-24 16:59 UTC (permalink / raw)
To: Simon Horman, Jacek Kowalski
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
On 4/24/2025 7:24 PM, Simon Horman wrote:
> On Tue, Apr 22, 2025 at 09:43:01AM +0200, Jacek Kowalski wrote:
>> Some Dell Tiger Lake systems have incorrect NVM checksum. These also
>> have a bitmask that indicates correct checksum set to "invalid".
>>
>> Because it is impossible to determine whether the NVM write would finish
>> correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
>> it makes sense to skip the validation completely under these conditions.
It is not completely accurate. All the NVMs starting from Tiger Lake are
locked for writes, so NVM writes will always result in a failure.
Perhaps something like this:
"
All the NVMs starting from Tiger Lake are locked for writes, so NVM
writes will always result in a failure. Since tgp devices were the first
to have this lock, some manufacturers didn't create a correct image
resulting in this wrong checksum issue. Therefore, it makes these
devices as a transition period, skip updating the checksum if the bit
wasn't set.
"
>>
>> Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
>> Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM checksum")
> I think that while the commit cited above relates to this problem,
> this bug actually dates back to the patch I'm citing immediately below.
> And I think we should cite that commit here. IOW, I'm suggesting:
>
> Fixes: fb776f5d57ee ("e1000e: Add support for Tiger Lake")
>
>> Cc: stable@vger.kernel.org
> That not withstanding, based on the commit message,
> and the use of e1000_pch_tgp in another Tiger Lake fix [1],
> I think this patch looks good.
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> [1] commit ffd24fa2fcc7 ("e1000e: Correct NVM checksum verification flow")
>
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-24 16:59 ` [Intel-wired-lan] " Lifshits, Vitaly
@ 2025-04-24 17:29 ` Jacek Kowalski
2025-04-27 13:26 ` Lifshits, Vitaly
0 siblings, 1 reply; 19+ messages in thread
From: Jacek Kowalski @ 2025-04-24 17:29 UTC (permalink / raw)
To: Lifshits, Vitaly, Simon Horman
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
Hi,
>>> Because it is impossible to determine whether the NVM write would finish
>>> correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
>>> it makes sense to skip the validation completely under these conditions.
> It is not completely accurate. All the NVMs starting from Tiger Lake are locked for writes, so NVM writes will always result in a failure.
Check my message in a thread of an earlier patch:
Message-ID: <1c4b00b6-f6e3-4b04-a129-24452df60903@jacekk.info>
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250407/047551.html
On my laptop NVM write operation *does not fail* (nor hangs), driver loads and ethtool shows corrected checksum.
This lasts only until module reload (rmmod/insmod) or reboot.
I guess only shadow RAM is updated (or something like that) and not the non-volatile memory, but the operation itself does not error out.
It might also be because I've disabled Secure Boot...
--
Best regards,
Jacek Kowalski
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-24 17:29 ` Jacek Kowalski
@ 2025-04-27 13:26 ` Lifshits, Vitaly
2025-04-28 16:43 ` Jacek Kowalski
0 siblings, 1 reply; 19+ messages in thread
From: Lifshits, Vitaly @ 2025-04-27 13:26 UTC (permalink / raw)
To: Jacek Kowalski, Simon Horman
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
On 4/24/2025 8:29 PM, Jacek Kowalski wrote:
> Hi,
>
>>>> Because it is impossible to determine whether the NVM write would
>>>> finish
>>>> correctly or hang (see
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=213667)
>>>> it makes sense to skip the validation completely under these
>>>> conditions.
>
>> It is not completely accurate. All the NVMs starting from Tiger Lake
>> are locked for writes, so NVM writes will always result in a failure.
>
> Check my message in a thread of an earlier patch:
>
> Message-ID: <1c4b00b6-f6e3-4b04-a129-24452df60903@jacekk.info>
> https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250407/047551.html
>
>
> On my laptop NVM write operation *does not fail* (nor hangs), driver
> loads and ethtool shows corrected checksum.
>
> This lasts only until module reload (rmmod/insmod) or reboot.
>
> I guess only shadow RAM is updated (or something like that) and not the
> non-volatile memory, but the operation itself does not error out.
Yeah, probably this is what happens.
>
> It might also be because I've disabled Secure Boot...
>
Anyway, I think that the commit message should be precise.
How about this?
Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
driver cannot perform checksum validation and correction. This means
that all NVM images must leave the factory with correct checksum and
checksum valid bit set. Since Tiger Lake devices were the first to have
this lock, some systems in the field did not meet this requirement.
Therefore, for these transitional devices we skip checksum update and
verification, if the valid bit is not set.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-27 13:26 ` Lifshits, Vitaly
@ 2025-04-28 16:43 ` Jacek Kowalski
2025-05-04 9:13 ` Lifshits, Vitaly
0 siblings, 1 reply; 19+ messages in thread
From: Jacek Kowalski @ 2025-04-28 16:43 UTC (permalink / raw)
To: Lifshits, Vitaly, Simon Horman
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
> Anyway, I think that the commit message should be precise.
> How about this?
>
> Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
> driver cannot perform checksum validation and correction. This means
> that all NVM images must leave the factory with correct checksum and
> checksum valid bit set. Since Tiger Lake devices were the first to have
> this lock, some systems in the field did not meet this requirement.
> Therefore, for these transitional devices we skip checksum update and
> verification, if the valid bit is not set.
Should I prepare v2 with this description?
--
Best regards,
Jacek Kowalski
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-28 16:43 ` Jacek Kowalski
@ 2025-05-04 9:13 ` Lifshits, Vitaly
0 siblings, 0 replies; 19+ messages in thread
From: Lifshits, Vitaly @ 2025-05-04 9:13 UTC (permalink / raw)
To: Jacek Kowalski, Simon Horman
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, intel-wired-lan,
netdev, linux-kernel
On 4/28/2025 7:43 PM, Jacek Kowalski wrote:
>> Anyway, I think that the commit message should be precise.
>> How about this?
>>
>> Starting from Tiger Lake, LAN NVM is locked for writes by SW, so the
>> driver cannot perform checksum validation and correction. This means
>> that all NVM images must leave the factory with correct checksum and
>> checksum valid bit set. Since Tiger Lake devices were the first to
>> have this lock, some systems in the field did not meet this
>> requirement. Therefore, for these transitional devices we skip
>> checksum update and verification, if the valid bit is not set.
>
> Should I prepare v2 with this description?
>
Yes, please.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-04-22 7:43 [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set Jacek Kowalski
2025-04-22 8:39 ` [Intel-wired-lan] " Lifshits, Vitaly
2025-04-24 16:24 ` Simon Horman
@ 2025-05-12 17:25 ` Vlad URSU
2025-05-15 4:39 ` [Intel-wired-lan] " Lifshits, Vitaly
2 siblings, 1 reply; 19+ messages in thread
From: Vlad URSU @ 2025-05-12 17:25 UTC (permalink / raw)
To: Jacek Kowalski, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
On 22.04.2025 10:43, Jacek Kowalski wrote:
> Some Dell Tiger Lake systems have incorrect NVM checksum. These also
> have a bitmask that indicates correct checksum set to "invalid".
>
> Because it is impossible to determine whether the NVM write would finish
> correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?id=213667)
> it makes sense to skip the validation completely under these conditions.
>
> Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
> Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM
> checksum")
> Cc: stable@vger.kernel.org
> ---
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> index 364378133526..df4e7d781cb1 100644
> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> @@ -4274,6 +4274,8 @@ static s32
> e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
> ret_val = e1000e_update_nvm_checksum(hw);
> if (ret_val)
> return ret_val;
> + } else if (hw->mac.type == e1000_pch_tgp) {
> + return 0;
> }
> }
>
This patch doesn't work for me on an Optiplex 5090 Micro (i5-10500T). I
did some debugging and the platform is recognized as Tiger Lake, by the
driver, but the checksum valid bit is set even though the checksum is
not valid.
The network controller works fine if I patch out the validation in
netdev.c. The checksum word at address 0x7e read using ethtool is 0xffff.
I'm also a bit confused about why the driver reports the mac type as
e1000_pch_tgp even though i5-10500T should be Comet Lake?
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-05-12 17:25 ` Vlad URSU
@ 2025-05-15 4:39 ` Lifshits, Vitaly
2025-05-15 19:07 ` Vlad URSU
0 siblings, 1 reply; 19+ messages in thread
From: Lifshits, Vitaly @ 2025-05-15 4:39 UTC (permalink / raw)
To: Vlad URSU, Jacek Kowalski, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
On 5/12/2025 8:25 PM, Vlad URSU wrote:
> On 22.04.2025 10:43, Jacek Kowalski wrote:
>> Some Dell Tiger Lake systems have incorrect NVM checksum. These also
>> have a bitmask that indicates correct checksum set to "invalid".
>>
>> Because it is impossible to determine whether the NVM write would finish
>> correctly or hang (see https://bugzilla.kernel.org/show_bug.cgi?
>> id=213667)
>> it makes sense to skip the validation completely under these conditions.
>>
>> Signed-off-by: Jacek Kowalski <Jacek@jacekk.info>
>> Fixes: 4051f68318ca9 ("e1000e: Do not take care about recovery NVM
>> checksum")
>> Cc: stable@vger.kernel.org
>> ---
>> drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/
>> net/ethernet/intel/e1000e/ich8lan.c
>> index 364378133526..df4e7d781cb1 100644
>> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
>> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
>> @@ -4274,6 +4274,8 @@ static s32
>> e1000_validate_nvm_checksum_ich8lan(struct e1000_hw *hw)
>> ret_val = e1000e_update_nvm_checksum(hw);
>> if (ret_val)
>> return ret_val;
>> + } else if (hw->mac.type == e1000_pch_tgp) {
>> + return 0;
>> }
>> }
>>
>
> This patch doesn't work for me on an Optiplex 5090 Micro (i5-10500T). I
> did some debugging and the platform is recognized as Tiger Lake, by the
> driver, but the checksum valid bit is set even though the checksum is
> not valid.
>
> The network controller works fine if I patch out the validation in
> netdev.c. The checksum word at address 0x7e read using ethtool is 0xffff.
>
> I'm also a bit confused about why the driver reports the mac type as
> e1000_pch_tgp even though i5-10500T should be Comet Lake?
The device is being recognized by the device ID. Probably the device you
have on your system is TGP.
Since the checksum word is 0xFFFF which is peculiar, can you dump the
whole NVM and share with us?
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-05-15 4:39 ` [Intel-wired-lan] " Lifshits, Vitaly
@ 2025-05-15 19:07 ` Vlad URSU
2025-06-01 10:19 ` Lifshits, Vitaly
0 siblings, 1 reply; 19+ messages in thread
From: Vlad URSU @ 2025-05-15 19:07 UTC (permalink / raw)
To: Lifshits, Vitaly, Jacek Kowalski, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
On 15.05.2025 07:39, Lifshits, Vitaly wrote:
> Since the checksum word is 0xFFFF which is peculiar, can you dump the
> whole NVM and share with us?
Sure, here's a dump of my NVM
Offset Values
------ ------
0x0000: d0 8e 79 07 78 c8 01 08 ff ff 44 00 01 00 6c 00
0x0010: ff ff ff ff c9 10 54 0a 28 10 f9 15 00 00 00 00
0x0020: 00 00 00 00 00 80 05 a7 30 30 00 16 00 00 00 0c
0x0030: f3 08 00 0a 43 08 13 01 f9 15 ad ba f9 15 fa 15
0x0040: ad ba f9 15 ad ba f9 15 00 00 80 80 00 4e 86 08
0x0050: 00 00 00 00 07 00 00 20 20 00 00 00 00 0e 00 00
0x0060: 00 00 00 40 28 12 07 40 ff ff ff ff ff ff ff ff
0x0070: ff ff ff ff ff ff ff ff ff ff 00 02 ff ff ff ff
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff
0x00a0: 94 b0 00 08 0a 00 04 90 b0 47 40 24 c2 e1 21 c3
0x00b0: 3f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 80 60 1f 00 00 48 10 00 40 60 1f 00 04 d3 11 00
0x00d0: 03 0a 12 00 00 00 1f 00 04 b4 30 00 1c 00 31 00
0x00e0: 06 b4 30 00 09 00 31 00 07 b4 30 00 10 00 31 00
0x00f0: 0a b4 30 00 18 00 31 00 0c b4 30 00 18 00 31 00
0x0100: 0d b4 30 00 18 00 31 00 01 fd 30 00 2c 9c 31 00
0x0110: 4c b6 30 00 05 00 31 00 ff ff ff ff ff ff ff ff
0x0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0410: 69 53 84 03 01 00 00 00 00 00 00 00 00 00 00 00
0x0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x04f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0530: 00 00 00 00 00 00 00 00 03 3d 00 00 00 00 00 00
0x0540: 00 00 00 00 00 00 00 00 00 00 00 00 bc 0c 00 00
0x0550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x05e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x05f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x06b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x06c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x06d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x06e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x06f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0790: 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
0x07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0810: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0820: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0830: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0840: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0850: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0860: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0870: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0890: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x08f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0910: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0920: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0930: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0940: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0950: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0960: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0970: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0990: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x09f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0a90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0aa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ab0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ac0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ad0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ae0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0af0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0b90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ba0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0be0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0bf0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0c90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ca0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ce0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0cf0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0d90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0da0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0db0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0dd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0de0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0df0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0e90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ea0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0eb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ec0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ed0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ee0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ef0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0f90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fa0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fc0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fd0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0ff0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-05-15 19:07 ` Vlad URSU
@ 2025-06-01 10:19 ` Lifshits, Vitaly
2025-06-02 18:44 ` Vlad URSU
0 siblings, 1 reply; 19+ messages in thread
From: Lifshits, Vitaly @ 2025-06-01 10:19 UTC (permalink / raw)
To: Vlad URSU, Jacek Kowalski, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
On 5/15/2025 10:07 PM, Vlad URSU wrote:
> On 15.05.2025 07:39, Lifshits, Vitaly wrote:
>> Since the checksum word is 0xFFFF which is peculiar, can you dump the
>> whole NVM and share with us?
>
> Sure, here's a dump of my NVM
>
> Offset Values
> ------ ------
> 0x0000: d0 8e 79 07 78 c8 01 08 ff ff 44 00 01 00 6c 00
> 0x0010: ff ff ff ff c9 10 54 0a 28 10 f9 15 00 00 00 00
> 0x0020: 00 00 00 00 00 80 05 a7 30 30 00 16 00 00 00 0c
> 0x0030: f3 08 00 0a 43 08 13 01 f9 15 ad ba f9 15 fa 15
> 0x0040: ad ba f9 15 ad ba f9 15 00 00 80 80 00 4e 86 08
You're right — I see that the SW compatibility bit is set and the
checksum appears to be incorrect.
Since the NVM is part of the system firmware and typically managed by
the system manufacturer, I recommend checking whether a firmware update
is available for your system as a first step.
If no update is available, perhaps we can consider ignoring the checksum
on TGP systems if one of the following conditions is met:
1. SW compatibility bit is not set (current Jacek's approach)
2. The checksum word at offset 0x3F retains its factory default value of
0xFFFF.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-06-01 10:19 ` Lifshits, Vitaly
@ 2025-06-02 18:44 ` Vlad URSU
2025-06-03 9:22 ` Lifshits, Vitaly
0 siblings, 1 reply; 19+ messages in thread
From: Vlad URSU @ 2025-06-02 18:44 UTC (permalink / raw)
To: Lifshits, Vitaly, Jacek Kowalski, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
On 01.06.2025 13:19, Lifshits, Vitaly wrote:
>
>
> On 5/15/2025 10:07 PM, Vlad URSU wrote:
>> On 15.05.2025 07:39, Lifshits, Vitaly wrote:
>>> Since the checksum word is 0xFFFF which is peculiar, can you dump the
>>> whole NVM and share with us?
>>
>> Sure, here's a dump of my NVM
>>
>> Offset Values
>> ------ ------
>> 0x0000: d0 8e 79 07 78 c8 01 08 ff ff 44 00 01 00 6c 00
>> 0x0010: ff ff ff ff c9 10 54 0a 28 10 f9 15 00 00 00 00
>> 0x0020: 00 00 00 00 00 80 05 a7 30 30 00 16 00 00 00 0c
>> 0x0030: f3 08 00 0a 43 08 13 01 f9 15 ad ba f9 15 fa 15
>> 0x0040: ad ba f9 15 ad ba f9 15 00 00 80 80 00 4e 86 08
>
> You're right — I see that the SW compatibility bit is set and the
> checksum appears to be incorrect.
>
> Since the NVM is part of the system firmware and typically managed by
> the system manufacturer, I recommend checking whether a firmware update
> is available for your system as a first step.
>
> If no update is available, perhaps we can consider ignoring the checksum
> on TGP systems if one of the following conditions is met:
> 1. SW compatibility bit is not set (current Jacek's approach)
> 2. The checksum word at offset 0x3F retains its factory default value of
> 0xFFFF.
I am already on the latest firmware. I have also tried downgrading to
earlier versions and they have the same problem.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-06-02 18:44 ` Vlad URSU
@ 2025-06-03 9:22 ` Lifshits, Vitaly
2025-06-03 21:00 ` Jacek Kowalski
0 siblings, 1 reply; 19+ messages in thread
From: Lifshits, Vitaly @ 2025-06-03 9:22 UTC (permalink / raw)
To: Vlad URSU, Jacek Kowalski, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
On 6/2/2025 9:44 PM, Vlad URSU wrote:
> On 01.06.2025 13:19, Lifshits, Vitaly wrote:
>>
>>
>> On 5/15/2025 10:07 PM, Vlad URSU wrote:
>>> On 15.05.2025 07:39, Lifshits, Vitaly wrote:
>>>> Since the checksum word is 0xFFFF which is peculiar, can you dump
>>>> the whole NVM and share with us?
>>>
>>> Sure, here's a dump of my NVM
>>>
>>> Offset Values
>>> ------ ------
>>> 0x0000: d0 8e 79 07 78 c8 01 08 ff ff 44 00 01 00 6c 00
>>> 0x0010: ff ff ff ff c9 10 54 0a 28 10 f9 15 00 00 00 00
>>> 0x0020: 00 00 00 00 00 80 05 a7 30 30 00 16 00 00 00 0c
>>> 0x0030: f3 08 00 0a 43 08 13 01 f9 15 ad ba f9 15 fa 15
>>> 0x0040: ad ba f9 15 ad ba f9 15 00 00 80 80 00 4e 86 08
>>
>> You're right — I see that the SW compatibility bit is set and the
>> checksum appears to be incorrect.
>>
>> Since the NVM is part of the system firmware and typically managed by
>> the system manufacturer, I recommend checking whether a firmware
>> update is available for your system as a first step.
>>
>> If no update is available, perhaps we can consider ignoring the
>> checksum on TGP systems if one of the following conditions is met:
>> 1. SW compatibility bit is not set (current Jacek's approach)
>> 2. The checksum word at offset 0x3F retains its factory default value
>> of 0xFFFF.
>
> I am already on the latest firmware. I have also tried downgrading to
> earlier versions and they have the same problem.
Ok, so in this case I think that we should go with option 2.
Jacek - can you please add this check to your patch?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set
2025-06-03 9:22 ` Lifshits, Vitaly
@ 2025-06-03 21:00 ` Jacek Kowalski
0 siblings, 0 replies; 19+ messages in thread
From: Jacek Kowalski @ 2025-06-03 21:00 UTC (permalink / raw)
To: Lifshits, Vitaly, Vlad URSU, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: intel-wired-lan, netdev, linux-kernel
>>> If no update is available, perhaps we can consider ignoring the
>>> checksum on TGP systems if one of the following conditions is met:
>>> 1. SW compatibility bit is not set (current Jacek's approach)
>>> 2. The checksum word at offset 0x3F retains its factory default value
>>> of 0xFFFF.
>>
>> I am already on the latest firmware. I have also tried downgrading to
>> earlier versions and they have the same problem.
>
> Ok, so in this case I think that we should go with option 2.
>
> Jacek - can you please add this check to your patch?
Yes, I'll prepare v2 by the end of this week.
--
Best regards,
Jacek Kowalski
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2025-06-03 21:00 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-22 7:43 [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set Jacek Kowalski
2025-04-22 8:39 ` [Intel-wired-lan] " Lifshits, Vitaly
2025-04-24 16:24 ` Simon Horman
2025-04-24 16:46 ` Jacek Kowalski
2025-04-24 17:18 ` Simon Horman
2025-04-24 17:37 ` Jacek Kowalski
2025-04-25 16:45 ` Simon Horman
2025-04-24 16:59 ` [Intel-wired-lan] " Lifshits, Vitaly
2025-04-24 17:29 ` Jacek Kowalski
2025-04-27 13:26 ` Lifshits, Vitaly
2025-04-28 16:43 ` Jacek Kowalski
2025-05-04 9:13 ` Lifshits, Vitaly
2025-05-12 17:25 ` Vlad URSU
2025-05-15 4:39 ` [Intel-wired-lan] " Lifshits, Vitaly
2025-05-15 19:07 ` Vlad URSU
2025-06-01 10:19 ` Lifshits, Vitaly
2025-06-02 18:44 ` Vlad URSU
2025-06-03 9:22 ` Lifshits, Vitaly
2025-06-03 21:00 ` Jacek Kowalski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).