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

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

[Wenger Jeremie (EDU)]

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

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

[Jakub Kicinski]

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?

> 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

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

[Wenger Jeremie (EDU)]

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@vger.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
    

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

[Lifshits, Vitaly]

On 1/8/2026 4:15 PM, Wenger Jeremie (EDU) via Intel-wired-lan 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.
> 
> 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:
> 
>  1.
> 
>     Boot with Ethernet cable plugged.
> 
>  2.
> 
>     Verify network connectivity works.
> 
>  3.
> 
>     Unplug the Ethernet cable.
> 
>  4.
> 
>     Plug the Ethernet cable back in.
> 
>  5.
> 
>     Observe that RX no longer works (no DHCP OFFER).
> 
>  6.
> 
>     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
> 
> 

Hi Jérémie,

Your issue sounds very similar to the issues that were addresses in this 
commit:
https://github.com/torvalds/linux/commit/3c7bf5af2196087f394f9099b53e37569636b259

Are you able to reproduce it over the latest kernel 6.19?

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

[Wenger Jeremie (EDU)]

De : Lifshits, Vitaly <vitaly.lifshits@intel.com>
Envoyé : mardi, 13 janvier 2026 04:05
À : Wenger Jeremie (EDU); netdev@vger.kernel.org
Cc : anthony.l.nguyen@intel.com; przemyslaw.kitszel@intel.com; intel-wired-lan@lists.osuosl.org; linux-kernel@vger.kernel.org
Objet : Re: [Intel-wired-lan] [REGRESSION] e1000e: RX stops after link down/up on Intel 8086:550a since v6.12.43 (fixed by suspend/resume)
    
PRUDENCE. Ce message provient d'un expéditeur externe à l'État. Ne cliquez sur les liens ou n'ouvrez les pièces jointes que si vous faites entière confiance à cet expéditeur.

On 1/8/2026 4:15 PM, Wenger Jeremie (EDU) via Intel-wired-lan 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.
>
> 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:
>
>  1.
>
>     Boot with Ethernet cable plugged.
>
>  2.
>
>     Verify network connectivity works.
>
>  3.
>
>     Unplug the Ethernet cable.
>
>  4.
>
>     Plug the Ethernet cable back in.
>
>  5.
>
>     Observe that RX no longer works (no DHCP OFFER).
>
>  6.
>
>     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
>
>

Hi Jérémie,

Your issue sounds very similar to the issues that were addresses in this
commit:
https://github.com/torvalds/linux/commit/3c7bf5af2196087f394f9099b53e37569636b259

Are you able to reproduce it over the latest kernel 6.19?

    

Hi Vitaly,

Yes, I can confirm this.

I tested with Linux 6.19 (6.19~rc4-1~exp1), and the issue is fixed there.
After an Ethernet link down/up, RX now recovers correctly without requiring
a suspend/resume cycle.

So this appears to be resolved by commit:
3c7bf5af2196087f394f9099b53e37569636b259

Do you know if this fix is planned to be backported to stable kernels
(e.g. 6.12.y), or if a backport would be acceptable?

Thanks again for your help.

Best regards,

Jérémie