From: <gregkh@linuxfoundation.org>
To: sasha.neftin@intel.com, aaron.f.brown@intel.com,
amit.pundir@linaro.org, dima.ruinskiy@intel.com,
gregkh@linuxfoundation.org, jeffrey.t.kirsher@intel.com,
raanan.avargil@intel.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "e1000e: fix buffer overrun while the I219 is processing DMA transactions" has been added to the 4.14-stable tree
Date: Tue, 28 Nov 2017 10:27:48 +0100 [thread overview]
Message-ID: <1511861268206192@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
e1000e: fix buffer overrun while the I219 is processing DMA transactions
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
e1000e-fix-buffer-overrun-while-the-i219-is-processing-dma-transactions.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From b10effb92e272051dd1ec0d7be56bf9ca85ab927 Mon Sep 17 00:00:00 2001
From: Sasha Neftin <sasha.neftin@intel.com>
Date: Sun, 6 Aug 2017 16:49:18 +0300
Subject: e1000e: fix buffer overrun while the I219 is processing DMA transactions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Sasha Neftin <sasha.neftin@intel.com>
commit b10effb92e272051dd1ec0d7be56bf9ca85ab927 upstream.
Intel® 100/200 Series Chipset platforms reduced the round-trip
latency for the LAN Controller DMA accesses, causing in some high
performance cases a buffer overrun while the I219 LAN Connected
Device is processing the DMA transactions. I219LM and I219V devices
can fall into unrecovered Tx hang under very stressfully UDP traffic
and multiple reconnection of Ethernet cable. This Tx hang of the LAN
Controller is only recovered if the system is rebooted. Slightly slow
down DMA access by reducing the number of outstanding requests.
This workaround could have an impact on TCP traffic performance
on the platform. Disabling TSO eliminates performance loss for TCP
traffic without a noticeable impact on CPU performance.
Please, refer to I218/I219 specification update:
https://www.intel.com/content/www/us/en/embedded/products/networking/
ethernet-connection-i218-family-documentation.html
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Reviewed-by: Raanan Avargil <raanan.avargil@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3021,8 +3021,8 @@ static void e1000_configure_tx(struct e1
hw->mac.ops.config_collision_dist(hw);
- /* SPT and CNP Si errata workaround to avoid data corruption */
- if (hw->mac.type >= e1000_pch_spt) {
+ /* SPT and KBL Si errata workaround to avoid data corruption */
+ if (hw->mac.type == e1000_pch_spt) {
u32 reg_val;
reg_val = er32(IOSFPC);
@@ -3030,7 +3030,9 @@ static void e1000_configure_tx(struct e1
ew32(IOSFPC, reg_val);
reg_val = er32(TARC(0));
- reg_val |= E1000_TARC0_CB_MULTIQ_3_REQ;
+ /* SPT and KBL Si errata workaround to avoid Tx hang */
+ reg_val &= ~BIT(28);
+ reg_val |= BIT(29);
ew32(TARC(0), reg_val);
}
}
Patches currently in stable-queue which might be from sasha.neftin@intel.com are
queue-4.14/e1000e-fix-buffer-overrun-while-the-i219-is-processing-dma-transactions.patch
next reply other threads:[~2017-11-28 9:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 9:27 gregkh [this message]
2017-11-28 9:56 ` Patch "e1000e: fix buffer overrun while the I219 is processing DMA transactions" has been added to the 4.14-stable tree Neftin, Sasha
2017-11-28 10:18 ` Greg KH
2017-11-28 19:23 ` Jeff Kirsher
2017-12-04 12:15 ` Greg KH
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=1511861268206192@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=aaron.f.brown@intel.com \
--cc=amit.pundir@linaro.org \
--cc=dima.ruinskiy@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=raanan.avargil@intel.com \
--cc=sasha.neftin@intel.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.