[Intel-wired-lan] Intel-wired-lan Digest, Vol 268, Issue 43, Replay to message number 6, Test hints request for e1000e: Relax condition to trigger reset for ME workaround patch

[Punit Agrawal]

Hi Amir,

"Avivi, Amir" <amir.avivi at intel.com> writes:

[...]

> Subject: [PATCH] e1000e: Relax condition to trigger reset for ME workaround
>
> It's an error if the value of the RX/TX tail descriptor does not match
> what was written. The error condition is true regardless the duration
> of the interference from ME. But the driver only performs the reset if
> E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have
> transpired. The extra condition can lead to inconsistency between the
> state of hardware as expected by the driver.
>
> Fix this by dropping the check for number of delay iterations.
>
> While at it, also make __ew32_prepare() static as it's not used
> anywhere else.
>
> Signed-off-by: Punit Agrawal <punit1.agrawal at toshiba.co.jp>
> Reviewed-by: Alexander Duyck <alexander.h.duyck at linux.intel.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher at intel.com>
> Cc: "David S. Miller" <davem at davemloft.net>
> Cc: intel-wired-lan at lists.osuosl.org
> Cc: netdev at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> ---
> Hi Jeff,
>
> If there are no further comments please consider merging the patch.
>
> Also, should it be marked for backport to stable?
>
> Thanks,
> Punit
>
> RFC[0] -> v1:
> * Dropped return value for __ew32_prepare() as it's not used
> * Made __ew32_prepare() static
> * Added tags
>
> [0] https://lkml.org/lkml/2020/5/12/02
>
>  drivers/net/ethernet/intel/e1000e/e1000.h  |  1 -
>  drivers/net/ethernet/intel/e1000e/netdev.c | 12 +++++-------
>  2 files changed, 5 insertions(+), 8 deletions(-)
>
> Tested-by: Aaron Brown <aaron.f.brown at intel.com>
>
> Thanks for taking the patch for a spin.
>
> Jeff, let me know if you're okay to apply the tag or want me to send a
> new version.
>
> Hi Punit,
> This patch appears to be effecting some legacy code effecting old
> hardware.

Indeed. The problem under investigation was reported on a machine
released ~2012 I think.

> We tried applying it but we could not get the driver to run the
> changed code lines.
> Please provide some test hints(What platforms did
> you check it on?  What tests did you run?) regarding this patch.

As mentioned in the original posting[0], the patch was based on code
investigation.

A backported version of the patch is running on a really old kernel
(2.6.x) and we haven't found any way to speed up reproduction - it takes
O(weeks) to hit the issue in the test environment.

[0] https://lkml.org/lkml/2020/5/12/20

[...]