netdev - RE: [REGRESSION] e1000e: RX stops after link down/up on Intel 8086:550a since v6.12.43 (fixed by suspend/resume)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <33854287fd02403093ff9f7dfa6412f1@edu.ge.ch>
Date: Wed, 14 Jan 2026 07:19:12 +0000
From: "Wenger Jeremie (EDU)" <jeremie.wenger@....ge.ch>
To: Jakub Kicinski <kuba@...nel.org>, "intel-wired-lan@...ts.osuosl.org"
	<intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Przemek
 Kitszel" <przemyslaw.kitszel@...el.com>, Tony Nguyen
	<anthony.l.nguyen@...el.com>
Subject: RE: [REGRESSION] e1000e: RX stops after link down/up on Intel
 8086:550a since v6.12.43 (fixed by suspend/resume)

Thanks for the report, I'm adding the relevant people to CC now.
Please try to consult the MAINTAINERS file next time 'cause networking
is a bit too big for the right people to always notice reports.

My best guess below..

On Fri, 9 Jan 2026 09:40:34 +0000 Wenger Jeremie (EDU) wrote:
> Hello,
>
> I would like to report a regression in the e1000e driver affecting an Intel integrated Ethernet controller.
>
> Hardware:
> Intel Ethernet controller  [8086:550a]
> Driver: e1000e
>
> Summary:
> - RX stops working after an Ethernet link down/up (unplug/replug cable).
> - TX still works. A system suspend/resume reliably restores RX.
>
> Regression range:
> - Working: v6.12.22
> - Broken: v6.12.43 .. v6.18.3 (tested on Debian 12 backports, Debian 13, Debian sid). v6.18.3 is the most recent kernel tested so far, so the regression is likely still present in newer kernels.

Judging by the range seems like it has to be efaaf344bc2917cb
Would you be able to try building a kernel with that commit reverted?



Hi,

Thanks for looking into this.

Just to provide some additional context and help avoid duplicated work:
the issue has also been discussed on netdev@...r.kernel.org, and I was pointed to a fix that landed in mainline.

I tested the issue with Linux 6.19 (6.19~rc4-1~exp1), and the problem is fully resolved there: RX correctly recovers after a link down/up without requiring a suspend/resume cycle.

This behavior change appears to be due to commit:
3c7bf5af2196087f394f9099b53e37569636b259

Given that current mainline works as expected, I did not attempt reverting efaaf344bc2917cb. I also asked on netdev whether a backport of the above fix to stable kernels would be appropriate.

Please let me know if you still think a targeted revert test would be useful.

Best regards,
Jérémie


> Symptoms:
> - Link is detected (1Gbps, full duplex).
> - DHCP DISCOVER frames are transmitted (confirmed via external packet capture).
> - No packets are received (no DHCP OFFER, RX appears dead).
> - Booting with the cable plugged works.
> - The issue is triggered only after unplugging and replugging the cable.
> - A suspend/resume cycle restores RX immediately.
> - Using a USB Ethernet adapter (r8152) on the same network works correctly.
>
> Reproduction steps:
> - Boot with Ethernet cable plugged.
> - Verify network connectivity works.
> - Unplug the Ethernet cable.
> - Plug the Ethernet cable back in.
> - Observe that RX no longer works (no DHCP OFFER).
> - Suspend/resume the system → RX works again.
>
> This suggests that the PHY or RX path is not correctly reinitialized on link up after a link down event, while the resume path performs a more complete reset.
>
> I can provide additional logs, ethtool statistics, or test patches if needed.
>
>
> Best regards,
>
> Jérémie Wenger