[PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Jacek Kowalski]

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

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Lifshits, Vitaly]

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>

Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Simon Horman]

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")

Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Jacek Kowalski]

>> 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

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Lifshits, Vitaly]

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")
>

Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Simon Horman]

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?

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Jacek Kowalski]

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

Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Jacek Kowalski]

> 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

Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Simon Horman]

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.

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Lifshits, Vitaly]

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.

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Jacek Kowalski]

> 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

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Lifshits, Vitaly]

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.

Re: [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Vlad URSU]

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?

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Lifshits, Vitaly]

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?

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Vlad URSU]

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

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Lifshits, Vitaly]

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.

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Vlad URSU]

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.

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Lifshits, Vitaly]

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?

Re: [Intel-wired-lan] [PATCH] e1000e: disregard NVM checksum on tgp when valid checksum mask is not set

[Jacek Kowalski]

>>> 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