Netplan bridge seems to break after waking up from suspend on igc network module

Support and Help
1

I only noticed this after I switched to Garuda Linux, and created a network bridge via Netplan. I thought, at first, that the it was the igc driver, but it could be a combo of both igc and bridge networking via Netplan.

I assumed that switching distros fixed my network issue because I was able to suspend just fine overnight.

However, that was short-lived since after I created this Netplan config to enable a network bridge on my gaming PC for my VMs, the issue cropped up again

network:
  version: 2
  ethernets:
    enp8s0:
      match:
        macaddress: d8:5e:d3:04:3d:59
      dhcp4: false
      dhcp6: false

  bridges:
    br0:
      macaddress: d8:5e:d3:04:3d:59
      interfaces:
        - enp8s0
      dhcp4: true
      dhcp6: true

Linux Y4M1-II 6.14.10-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Wed, 04 Jun 2025 18:52:21 +0000 x86_64 GNU/Linux

Before I switched to Garuda, I was on Tuxedo OS (Ubuntu) and tested with kernels 6.11 & 6.14 (Liquorix & Zen)

On another note: it seems my suspend problems were solved by switching to Garuda

2

It isn’t Netplan itself that prevents your machine from suspending; the snag is Intel’s igc driver for the I225/I226 NIC. The bug shows up only when the NIC is placed in promiscuous / bridge mode, which is exactly what happens as soon as you enslave enp8s0 to br0. The driver’s power-management routine then fails and the kernel never finishes the suspend sequence. (Same thing has been reported on Ubuntu and Fedora whenever a libvirt/KVM bridge is active.)

Delete the forced MAC addresses in your Netplan file.
A bridge automatically inherits the MAC of its first slave. If you hard-code the same address on both enp8s0 and br0, the igc firmware can get confused.
Edit the YAML, remove every macaddress: line, and run sudo netplan apply. Then test suspend again.

Turn off Wake-on-LAN on the NIC.
The buggy code path lives in the WoL handler.

sudo ethtool -s enp8s0 wol d

If that helps, make it permanent with either a small udev rule or an ethtool: stanza in your Netplan file.

Try Intel’s newest out-of-tree igc driver.
Intel already posted a patch; it just hasn’t landed in mainline 6.14-zen yet. Download their tarball, build it, then:

sudo modprobe -r igc
sudo insmod ./igc.ko

Suspend again; if it now works you can wait for the fix to reach the standard kernels.

As a temporary workaround, drop the bridge before sleep.
Create /usr/lib/systemd/system-sleep/bridge-down, make it executable, and put this inside:

#!/bin/sh
[ "$1" = pre  ] && ip link set br0 down
[ "$1" = post ] && ip link set br0 up

Systemd will bring the bridge down right before suspend and back up on resume.

Test without the bridge at all.
Comment out the entire bridges: block, run sudo netplan apply, and see if suspend suddenly works every time. If it does, that confirms the bridge + igc combo is the only trigger.

Once enp8s0 is part of br0, the current igc driver’s power-management routine stumbles. Cleaning up the Netplan file (no duplicate MACs) and disabling WoL fixes it for many users; otherwise you’ll need either Intel’s patched module or a newer kernel when the fix merges. Good luck getting that gaming PC back to sleep peacefully!

1 Like