Skip to contentSkip to conversation

e1000e: Upstream fixes for linux-4.14.y

PATCH In review Amit Pundir 5 participants 19 messages Nov 27, 2017 – Jan 1, 2018

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

cover e1000e: Upstream fixes for linux-4.14.y

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

 drivers/net/ethernet/intel/e1000e/defines.h |  1 +
 drivers/net/ethernet/intel/e1000e/mac.c     | 11 +++++--
 drivers/net/ethernet/intel/e1000e/netdev.c  | 45 ++++++++++++++++++++---------
 drivers/net/ethernet/intel/e1000e/phy.c     |  7 +++--
 4 files changed, 45 insertions(+), 19 deletions(-)
Signature · 1 line
2.7.4
#1 lore raw

PATCH 1/5 e1000e: Fix error path in link detection

From: Benjamin Poirier <[email protected]>

commit c4c40e51f9c32c6dd8adf606624c930a1c4d9bbb upstream.

In case of error from e1e_rphy(), the loop will exit early and "success" will be set to true erroneously.

---
 drivers/net/ethernet/intel/e1000e/phy.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/e1000e/phy.c +4 -3
index d78d47b41a71..86ff0969efb6 100644
@@ -1744,6 +1744,7 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
 	s32 ret_val = 0;
 	u16 i, phy_status;
 
+	*success = false;
 	for (i = 0; i < iterations; i++) {
 		/* Some PHYs require the MII_BMSR register to be read
 		 * twice due to the link bit being sticky.  No harm doing
@@ -1763,16 +1764,16 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
 		ret_val = e1e_rphy(hw, MII_BMSR, &phy_status);
 		if (ret_val)
 			break;
-		if (phy_status & BMSR_LSTATUS)
+		if (phy_status & BMSR_LSTATUS) {
+			*success = true;
 			break;
+		}
 		if (usec_interval >= 1000)
 			msleep(usec_interval / 1000);
 		else
 			udelay(usec_interval);
 	}
 
-	*success = (i < iterations);
-
 	return ret_val;
 }
 
Signature · 1 line
2.7.4
#2 lore raw

PATCH 2/5 e1000e: Fix return value test

In reply to Amit Pundir

From: Benjamin Poirier <[email protected]>

commit d3509f8bc7b0560044c15f0e3ecfde1d9af757a6 upstream.

All the helpers return -E1000_ERR_PHY.

---
 drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/e1000e/netdev.c +1 -1
index 327dfe5bedc0..764a6bd958ac 100644
@@ -5099,7 +5099,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
 		break;
 	}
 
-	if ((ret_val == E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) &&
+	if ((ret_val == -E1000_ERR_PHY) && (hw->phy.type == e1000_phy_igp_3) &&
 	    (er32(CTRL) & E1000_PHY_CTRL_GBE_DISABLE)) {
 		/* See e1000_kmrn_lock_loss_workaround_ich8lan() */
 		e_info("Gigabit has been disabled, downgrading speed\n");
Signature · 1 line
2.7.4
#3 lore raw

PATCH 3/5 e1000e: Separate signaling for link check/link up

In reply to Amit Pundir

From: Benjamin Poirier <[email protected]>

commit 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 upstream.

Lennart reported the following race condition:

\ e1000_watchdog_task

    \ e1000e_has_link
        \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link
            /* link is up */
            mac->get_link_status = false;

                            /* interrupt */
                            \ e1000_msix_other
                                hw->mac.get_link_status = true;

        link_active = !hw->mac.get_link_status
        /* link_active is false, wrongly */

This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down.

Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link().

---
 drivers/net/ethernet/intel/e1000e/mac.c    | 11 ++++++++---
 drivers/net/ethernet/intel/e1000e/netdev.c |  2 +-
 2 files changed, 9 insertions(+), 4 deletions(-)
drivers/net/ethernet/intel/e1000e/mac.c +8 -3
index b322011ec282..f457c5703d0c 100644
@@ -410,6 +410,9 @@ void e1000e_clear_hw_cntrs_base(struct e1000_hw *hw)
  *  Checks to see of the link status of the hardware has changed.  If a
  *  change in link status has been detected, then we read the PHY registers
  *  to get the current speed/duplex if link exists.
+ *
+ *  Returns a negative error code (-E1000_ERR_*) or 0 (link down) or 1 (link
+ *  up).
  **/
 s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
 {
@@ -423,7 +426,7 @@ s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
 	 * Change or Rx Sequence Error interrupt.
 	 */
 	if (!mac->get_link_status)
-		return 0;
+		return 1;
 
 	/* First we want to see if the MII Status Register reports
 	 * link.  If so, then we want to get the current speed/duplex
@@ -461,10 +464,12 @@ s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
 	 * different link partner.
 	 */
 	ret_val = e1000e_config_fc_after_link_up(hw);
-	if (ret_val)
+	if (ret_val) {
 		e_dbg("Error configuring flow control\n");
+		return ret_val;
+	}
 
-	return ret_val;
+	return 1;
 }
 
 /**
drivers/net/ethernet/intel/e1000e/netdev.c +1 -1
index 764a6bd958ac..83071fe99323 100644
@@ -5081,7 +5081,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
 	case e1000_media_type_copper:
 		if (hw->mac.get_link_status) {
 			ret_val = hw->mac.ops.check_for_link(hw);
-			link_active = !hw->mac.get_link_status;
+			link_active = ret_val > 0;
 		} else {
 			link_active = true;
 		}
Signature · 1 line
2.7.4
#4 lore raw

PATCH 4/5 e1000e: Avoid receiver overrun interrupt bursts

In reply to Amit Pundir

From: Benjamin Poirier <[email protected]>

commit 4aea7a5c5e940c1723add439f4088844cd26196d upstream.

When e1000e_poll() is not fast enough to keep up with incoming traffic, the adapter (when operating in msix mode) raises the Other interrupt to signal Receiver Overrun.

This is a double problem because 1) at the moment e1000_msix_other() assumes that it is only called in case of Link Status Change and 2) if the condition persists, the interrupt is repeatedly raised again in quick succession.

Ideally we would configure the Other interrupt to not be raised in case of receiver overrun but this doesn't seem possible on this adapter. Instead, we handle the first part of the problem by reverting to the practice of reading ICR in the other interrupt handler, like before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit 0a8047ac68e5 ("e1000e: Fix msi-x interrupt automask") which cleared IAME from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts anymore. We handle the second part of the problem by not re-enabling the Other interrupt right away when there is overrun. Instead, we wait until traffic subsides, napi polling mode is exited and interrupts are re-enabled.

Fixes 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt")
---
 drivers/net/ethernet/intel/e1000e/defines.h |  1 +
 drivers/net/ethernet/intel/e1000e/netdev.c  | 33 ++++++++++++++++++++++-------
 2 files changed, 26 insertions(+), 8 deletions(-)
drivers/net/ethernet/intel/e1000e/defines.h +1 -0
index 0641c0098738..afb7ebe20b24 100644
@@ -398,6 +398,7 @@
 #define E1000_ICR_LSC           0x00000004 /* Link Status Change */
 #define E1000_ICR_RXSEQ         0x00000008 /* Rx sequence error */
 #define E1000_ICR_RXDMT0        0x00000010 /* Rx desc min. threshold (0) */
+#define E1000_ICR_RXO           0x00000040 /* Receiver Overrun */
 #define E1000_ICR_RXT0          0x00000080 /* Rx timer intr (ring 0) */
 #define E1000_ICR_ECCER         0x00400000 /* Uncorrectable ECC Error */
 /* If this bit asserted, the driver should claim the interrupt */
drivers/net/ethernet/intel/e1000e/netdev.c +25 -8
index 83071fe99323..99e5ef561f06 100644
@@ -1910,14 +1910,30 @@ static irqreturn_t e1000_msix_other(int __always_unused irq, void *data)
 	struct net_device *netdev = data;
 	struct e1000_adapter *adapter = netdev_priv(netdev);
 	struct e1000_hw *hw = &adapter->hw;
+	u32 icr;
+	bool enable = true;
+
+	icr = er32(ICR);
+	if (icr & E1000_ICR_RXO) {
+		ew32(ICR, E1000_ICR_RXO);
+		enable = false;
+		/* napi poll will re-enable Other, make sure it runs */
+		if (napi_schedule_prep(&adapter->napi)) {
+			adapter->total_rx_bytes = 0;
+			adapter->total_rx_packets = 0;
+			__napi_schedule(&adapter->napi);
+		}
+	}
+	if (icr & E1000_ICR_LSC) {
+		ew32(ICR, E1000_ICR_LSC);
+		hw->mac.get_link_status = true;
+		/* guard against interrupt when we're going down */
+		if (!test_bit(__E1000_DOWN, &adapter->state))
+			mod_timer(&adapter->watchdog_timer, jiffies + 1);
+	}
 
-	hw->mac.get_link_status = true;
-
-	/* guard against interrupt when we're going down */
-	if (!test_bit(__E1000_DOWN, &adapter->state)) {
-		mod_timer(&adapter->watchdog_timer, jiffies + 1);
+	if (enable && !test_bit(__E1000_DOWN, &adapter->state))
 		ew32(IMS, E1000_IMS_OTHER);
-	}
 
 	return IRQ_HANDLED;
 }
@@ -2687,7 +2703,8 @@ static int e1000e_poll(struct napi_struct *napi, int weight)
 		napi_complete_done(napi, work_done);
 		if (!test_bit(__E1000_DOWN, &adapter->state)) {
 			if (adapter->msix_entries)
-				ew32(IMS, adapter->rx_ring->ims_val);
+				ew32(IMS, adapter->rx_ring->ims_val |
+				     E1000_IMS_OTHER);
 			else
 				e1000_irq_enable(adapter);
 		}
@@ -4204,7 +4221,7 @@ static void e1000e_trigger_lsc(struct e1000_adapter *adapter)
 	struct e1000_hw *hw = &adapter->hw;
 
 	if (adapter->msix_entries)
-		ew32(ICS, E1000_ICS_OTHER);
+		ew32(ICS, E1000_ICS_LSC | E1000_ICS_OTHER);
 	else
 		ew32(ICS, E1000_ICS_LSC);
 }
Signature · 1 line
2.7.4
#5 lore raw

PATCH 5/5 e1000e: fix buffer overrun while the I219 is processing DMA transactions

In reply to Amit Pundir

From: Sasha Neftin <[email protected]>

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

---
 drivers/net/ethernet/intel/e1000e/netdev.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/net/ethernet/intel/e1000e/netdev.c +5 -3
index 99e5ef561f06..c38b00c90f48 100644
@@ -3021,8 +3021,8 @@ static void e1000_configure_tx(struct e1000_adapter *adapter)
 
 	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 e1000_adapter *adapter)
 		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);
 	}
 }
Signature · 1 line
2.7.4
maintainer
#6 lore raw
In reply to Amit Pundir
Quoted 9 lines · Amit Pundir

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Any reason you did not cc: the maintainers for this driver and their mailing list?

Also, why is the maintainers of this driver not marking anything for stable? They never do, is that for a reason?

thanks,

greg k-h

#7 lore raw

cover e1000e: Upstream fixes for linux-4.14.y

+ Jeff and intel-wired-lan (moderated) mailing list.

Quoted 7 lines · Greg KH
Quoted 6 lines · Amit Pundir

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Quoted 7 lines
Quoted 3 lines

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Any reason you did not cc: the maintainers for this driver and their mailing list?

No reason at all. Thanks for pointing that out. It didn't occur to me to do that. I was marking only patch authors in cover letters so far. I'll start adding respective maintainers and mailing list going forward.

Quoted 7 lines

Also, why is the maintainers of this driver not marking anything for stable? They never do, is that for a reason?

thanks,

greg k-h

Regards,
Amit Pundir

maintainer
#8 lore raw

cover e1000e: Upstream fixes for linux-4.14.y

Quoted 15 lines · Amit Pundir

+ Jeff and intel-wired-lan (moderated) mailing list.

Quoted 12 lines · Greg KH
Quoted 9 lines · Amit Pundir

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Quoted 7 lines
Quoted 2 lines

Any reason you did not cc: the maintainers for this driver and their mailing list?

No reason at all. Thanks for pointing that out. It didn't occur to me to do that. I was marking only patch authors in cover letters so far. I'll start adding respective maintainers and mailing list going forward.

Thanks, please do that. All now queued up.

greg k-h

#9 lore raw

cover e1000e: Upstream fixes for linux-4.14.y

In reply to Amit Pundir
Quoted 14 lines · Amit Pundir

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Quoted 5 lines

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Also all the above fixes from Benjamin Poirier are to be marked for 4.9 and first 3 fixes for 4.4, 3.18 as well. Build tested for ARCH=arm/arm64.

Regards,
Amit Pundir

Quoted 14 lines

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

 drivers/net/ethernet/intel/e1000e/defines.h |  1 +
 drivers/net/ethernet/intel/e1000e/mac.c     | 11 +++++--
 drivers/net/ethernet/intel/e1000e/netdev.c  | 45 ++++++++++++++++++++---------
 drivers/net/ethernet/intel/e1000e/phy.c     |  7 +++--
 4 files changed, 45 insertions(+), 19 deletions(-)

--
2.7.4

#10 lore raw
In reply to Amit Pundir

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 20 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Quoted 3 lines

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

Hello everybody,

looks like one of these breaks connectivity on my Thinkpad X250. Just downgraded to linux 4.14.2 to verify.

Signature · 3 lines
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}
maintainer
#11 lore raw
Quoted 21 lines · Christian Hesse

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 20 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Quoted 8 lines
Quoted 3 lines

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

Hello everybody,

looks like one of these breaks connectivity on my Thinkpad X250. Just downgraded to linux 4.14.2 to verify.

Can you try the -rc release I just did? It has a fix for this series in it.

thanks,

greg k-h

#12 lore raw

Greg KH <[email protected]> on Mon, 2017/12/04 19:37:

Quoted 26 lines · Christian Hesse
Quoted 25 lines

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 23 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

Quoted 7 lines
Quoted 4 lines

Hello everybody,

looks like one of these breaks connectivity on my Thinkpad X250. Just downgraded to linux 4.14.2 to verify.

Can you try the -rc release I just did? It has a fix for this series in it.

It connects with the notebook's built in ethernet port (did not check with 4.14.3) but still fails to see a link when placed in docking station.

Signature · 3 lines
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}
maintainer
#13 lore raw
Quoted 29 lines · Christian Hesse

Greg KH <[email protected]> on Mon, 2017/12/04 19:37:

Quoted 28 lines · Christian Hesse
Quoted 27 lines

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 20 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Quoted 3 lines

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

Hello everybody,

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

looks like one of these breaks connectivity on my Thinkpad X250. Just downgraded to linux 4.14.2 to verify.

Can you try the -rc release I just did? It has a fix for this series in it.

It connects with the notebook's built in ethernet port (did not check with 4.14.3) but still fails to see a link when placed in docking station.

Do you have the same issues with 4.15-rc2?

thanks,

greg k-h

#14 lore raw

Greg KH <[email protected]> on Tue, 2017/12/05 08:35:

Quoted 33 lines · Christian Hesse
Quoted 32 lines

Greg KH <[email protected]> on Mon, 2017/12/04 19:37:

Quoted 31 lines · Christian Hesse
Quoted 29 lines

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 20 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Quoted 3 lines

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

Hello everybody,

looks like one of these breaks connectivity on my Thinkpad X250. Just downgraded to linux 4.14.2 to verify.

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Can you try the -rc release I just did? It has a fix for this series in it.

It connects with the notebook's built in ethernet port (did not check with 4.14.3) but still fails to see a link when placed in docking station.

Do you have the same issues with 4.15-rc2?

Just a short heads-up and final result for this thread... The issue is fixed with Benjamin's patch:

https://patchwork.kernel.org/patch/10104349/

Signature · 3 lines
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}
maintainer
#15 lore raw
Quoted 40 lines · Christian Hesse

Greg KH <[email protected]> on Tue, 2017/12/05 08:35:

Quoted 39 lines · Christian Hesse
Quoted 37 lines

Greg KH <[email protected]> on Mon, 2017/12/04 19:37:

Quoted 26 lines · Christian Hesse
Quoted 25 lines

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 23 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

Quoted 7 lines
Quoted 4 lines

Hello everybody,

looks like one of these breaks connectivity on my Thinkpad X250. Just downgraded to linux 4.14.2 to verify.

Can you try the -rc release I just did? It has a fix for this series in it.

It connects with the notebook's built in ethernet port (did not check with 4.14.3) but still fails to see a link when placed in docking station.

Quoted 6 lines
Quoted 1 line

Do you have the same issues with 4.15-rc2?

Just a short heads-up and final result for this thread... The issue is fixed with Benjamin's patch:

https://patchwork.kernel.org/patch/10104349/

Any word on getting this patch into Linus's tree anytime soon?

thanks,

greg k-h

#16 lore raw
Quoted 41 lines · Greg KH
Quoted 40 lines · Christian Hesse

Greg KH <[email protected]> on Tue, 2017/12/05 08:35:

Quoted 39 lines · Christian Hesse
Quoted 37 lines

Greg KH <[email protected]> on Mon, 2017/12/04 19:37:

Quoted 26 lines · Christian Hesse
Quoted 25 lines

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 23 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede source tree, https://git.lede-project.org/?p=source.git, and these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing DMA
transactions

Quoted 7 lines
Quoted 4 lines

Hello everybody,

looks like one of these breaks connectivity on my Thinkpad X250. Just downgraded to linux 4.14.2 to verify.

Can you try the -rc release I just did? It has a fix for this series in it.

It connects with the notebook's built in ethernet port (did not check with 4.14.3) but still fails to see a link when placed in docking station.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Do you have the same issues with 4.15-rc2?

Just a short heads-up and final result for this thread... The issue is fixed with Benjamin's patch:

https://patchwork.kernel.org/patch/10104349/

Any word on getting this patch into Linus's tree anytime soon?

Apparently the intel maintainer was unavailable recently:
https://www.mail-archive.com/[email protected]/msg206192.html

The patch is now in there:
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/log/?h=dev-queue
but that only makes it slated for 4.16 AFAIK.

Jeff, given that this issue breaks networking for many people, wouldn't it be more appropriate to submit the patch for 4.15?

#17 lore raw
Quoted 65 lines · Benjamin Poirier
Quoted 52 lines · Greg KH
Quoted 51 lines · Christian Hesse

Greg KH <[email protected]> on Tue, 2017/12/05 08:35:

Quoted 50 lines · Christian Hesse
Quoted 48 lines

Greg KH <[email protected]> on Mon, 2017/12/04 19:37:

Quoted 35 lines
Quoted 33 lines · Christian Hesse

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 24 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede
source tree, https://git.lede-project.org/?p=source.git,
and
these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Quoted 4 lines

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing
DMA
transactions

Hello everybody,

Quoted 7 lines
Quoted 3 lines

looks like one of these breaks connectivity on my Thinkpad X250.
Just downgraded to linux 4.14.2 to verify.

Can you try the -rc release I just did? It has a fix for this series in
it.

It connects with the notebook's built in ethernet port (did not check with
4.14.3) but still fails to see a link when placed in docking station.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Do you have the same issues with 4.15-rc2?

Just a short heads-up and final result for this thread... The issue is fixed with Benjamin's patch:

https://patchwork.kernel.org/patch/10104349/

Any word on getting this patch into Linus's tree anytime soon?

Apparently the intel maintainer was unavailable recently:
https://www.mail-archive.com/[email protected]/msg206192.html

Quoted 7 lines

The patch is now in there:
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/l
og/?h=dev-queue
but that only makes it slated for 4.16 AFAIK.

Jeff, given that this issue breaks networking for many people, wouldn't it be more appropriate to submit the patch for 4.15?

Yeah, I will send to Dave's net tree (4.15) for inclusion.

#18 lore raw
Quoted 71 lines · Jeff Kirsher
Quoted 70 lines · Benjamin Poirier
Quoted 52 lines · Greg KH
Quoted 51 lines · Christian Hesse

Greg KH <[email protected]> on Tue, 2017/12/05 08:35:

Quoted 50 lines · Christian Hesse
Quoted 48 lines

Greg KH <[email protected]> on Mon, 2017/12/04 19:37:

Quoted 35 lines
Quoted 33 lines · Christian Hesse

Amit Pundir <[email protected]> on Mon, 2017/11/27 18:23:

Quoted 24 lines

Hi Greg,

Found few e100e upstream fixes from Benjamin Poirier in lede
source tree, https://git.lede-project.org/?p=source.git,
and
these fixes seem reasonable enough for 4.14.y too.

Also submitting an e1000e buffer overrun fix by Sasha Neftin.

Cherry-picked and build tested for linux v4.14.2 for ARCH=arm/arm64.

Regards,
Amit Pundir

Benjamin Poirier (4):
e1000e: Fix error path in link detection
e1000e: Fix return value test
e1000e: Separate signaling for link check/link up
e1000e: Avoid receiver overrun interrupt bursts

Quoted 4 lines

Sasha Neftin (1):
e1000e: fix buffer overrun while the I219 is processing
DMA
transactions

Hello everybody,

Quoted 7 lines
Quoted 3 lines

looks like one of these breaks connectivity on my Thinkpad X250.
Just downgraded to linux 4.14.2 to verify.

Can you try the -rc release I just did? It has a fix for this series in
it.

It connects with the notebook's built in ethernet port (did not check with
4.14.3) but still fails to see a link when placed in docking station.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Do you have the same issues with 4.15-rc2?

Just a short heads-up and final result for this thread... The issue is fixed with Benjamin's patch:

https://patchwork.kernel.org/patch/10104349/

Any word on getting this patch into Linus's tree anytime soon?

Apparently the intel maintainer was unavailable recently:
https://www.mail-archive.com/[email protected]/msg206192.html

The patch is now in there:
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git/l
og/?h=dev-queue
but that only makes it slated for 4.16 AFAIK.

Quoted 4 lines
Quoted 2 lines

Jeff, given that this issue breaks networking for many people, wouldn't it be more appropriate to submit the patch for 4.15?

Yeah, I will send to Dave's net tree (4.15) for inclusion.

Jeff, I see that the patch is still in your "next-queue". Meanwhile another 4.15 rc has been released and I've gotten more user reports that e1000e is broken.