igc: I226-V does not wake from S5, PHPM D3 link-disable bits never cleared

igc: I226-V does not wake from S5, PHPM D3 link-disable bits never cleared

[Michael Serajnik]

Hello,

Wake-on-LAN from soft-off (S5) does not work with the I226-V on my
board under Linux. As far as I can tell, the cause is that igc never
clears the D3 link-disable bits in PHPM, which the NVM sets.

Hardware and software:
- Board: ASUS ROG STRIX B850-I GAMING WIFI, BIOS 1063 (AMD B850)
- NIC: Intel I226-V [8086:125c] rev 06, subsystem 1043:8867,
  at 0000:0a:00.0 behind an AMD 600 series chipset downstream port
- NVM: 2023:889d
- Kernel: 7.2.9 (Fedora-based Bazzite kernel); the code paths below
  are unchanged in current mainline

What I see:
- `ethtool eno1` shows "Supports Wake-on: pumbg" and "Wake-on: g".
- BIOS: ErP disabled, Power On By PCI-E enabled.
- /proc/acpi/wakeup has the NIC and every port on its path enabled.
- After `systemctl poweroff`, the port LEDs go dark, the switch sees
  no link, and a magic packet from the same subnet does not wake the
  machine.

Register read:
With igc unbound (strict devmem refuses the mmap while it is bound),
I read BAR0 + 0xE14 (IGC_I225_PHPM):

  PHPM = 0x00045298
  DIS_1000_D3 (0x0008), DIS_100_D3 (0x0200), DIS_2500_D3 (0x1000)
  are all set (mask 0x1208).

As a sanity check, RAL0 (0x5400) read 0x62e7fcbc, which matches the
MAC address bc:fc:e7:62:d6:2f.

These bits come from the NIC's NVM, not from the board firmware, and
FreeBSD bug 282140 (below) reports the same link-disable bits on other
hardware, so I do not expect a BIOS update to change this. [1]

With all three speeds disabled in D3, the PHY has no link while the
device is in D3, so the magic packet never reaches the MAC, however
WUFC is programmed. In mainline igc, `__igc_shutdown()` sets WUC,
WUFC and CTRL.ADVD3WUC and calls `igc_power_up_link()`, but nothing
in the driver clears these PHPM bits, and igc defines neither the
bits nor a D3 LPLU operation.

FreeBSD's igc(4) has the same problem: FreeBSD bug 282140 describes
the same NVM default (PHPM 0x00045398, same 0x1208 bits) and a
proposed fix that clears the D3 link-disable bits on the wake-arming
path and restores them when the PHY is powered down.

Could igc clear these bits when Wake-on-LAN is armed? I have not written
or tested a fix.

An agent (Claude Opus 5.5) helped me analyze this problem and write this
report. I ran the commands and checks on the machine myself and read up
on the background, so I can follow the analysis.

Thanks,
Michael Serajnik

[1] I have not updated the BIOS yet because of reports of dying Ryzen 7
    9800X3D CPUs (the CPU in this machine) with various BIOS versions,
    and none of the newer versions' release notes mention anything
    Ethernet-related.

Re: igc: I226-V does not wake from S5, PHPM D3 link-disable bits never cleared

[Ruinskiy, Dima]

On 17/10/2026 13:14, Michael Serajnik wrote:

> What I see:
> - `ethtool eno1` shows "Supports Wake-on: pumbg" and "Wake-on: g".
> - BIOS: ErP disabled, Power On By PCI-E enabled.
> - /proc/acpi/wakeup has the NIC and every port on its path enabled.
> - After `systemctl poweroff`, the port LEDs go dark, the switch sees
>    no link, and a magic packet from the same subnet does not wake the
>    machine.
> 
> Register read:
> With igc unbound (strict devmem refuses the mmap while it is bound),
> I read BAR0 + 0xE14 (IGC_I225_PHPM):
> 
>    PHPM = 0x00045298
>    DIS_1000_D3 (0x0008), DIS_100_D3 (0x0200), DIS_2500_D3 (0x1000)
>    are all set (mask 0x1208).
> 
> As a sanity check, RAL0 (0x5400) read 0x62e7fcbc, which matches the
> MAC address bc:fc:e7:62:d6:2f.
> 
> These bits come from the NIC's NVM, not from the board firmware, and
> FreeBSD bug 282140 (below) reports the same link-disable bits on other
> hardware, so I do not expect a BIOS update to change this. [1]
> 
> With all three speeds disabled in D3, the PHY has no link while the
> device is in D3, so the magic packet never reaches the MAC, however
> WUFC is programmed. In mainline igc, `__igc_shutdown()` sets WUC,
> WUFC and CTRL.ADVD3WUC and calls `igc_power_up_link()`, but nothing
> in the driver clears these PHPM bits, and igc defines neither the
> bits nor a D3 LPLU operation.

Hi Michael,

With these bits cleared, the link should resolve to the lowest, 10Mbps 
speed. In recent years, an increasing number of switches stopped 
supporting 10Mbps, so we have been receiving reports of similar problems 
from time to time.

I think I can fix it in the driver, but to double-check that the problem 
is indeed this, and not something else in the wake-from-shutdown path, 
could you try to reproduce with a different link partner (switch or 
back-to-back) that is known to support 10Mbps link speed?

Thanks!
--Dima

Re: igc: I226-V does not wake from S5, PHPM D3 link-disable bits never cleared

[Michael Serajnik]

Hi Dima,

Thanks for looking into this.

On 20/10/2026 09:55, Ruinskiy, Dima wrote:
> I think I can fix it in the driver, but to double-check that the problem
> is indeed this, and not something else in the wake-from-shutdown path,
> could you try to reproduce with a different link partner (switch or
> back-to-back) that is known to support 10Mbps link speed?

I can't easily swap the link partner. The PC is connected directly to an
ASUS RT-AX88U Pro router, on its 2.5G LAN port, and I have no other
switch to put in between. The cables are clamped down tightly along the
furniture with no slack to reach another port, so trying a different
port would mean moving the furniture and re-running the cables. Since
this is mostly an annoyance and does not break anything, I would rather
not do that at this point. It is also unclear whether it would help:
ASUS labels the 2.5G port "2.5G/1G LAN" and lists the four other LAN
ports as gigabit, without saying whether any of them supports 10 or
100 Mbps.

Instead, I restricted the I226-V's advertisement while the system was
running and waited 30 seconds each time:

  ethtool -s eno1 advertise 0x003   (10baseT only)
    no link (Speed: Unknown!, Link detected: no)

  ethtool -s eno1 advertise 0x00c   (100baseT only)
    "NIC Link is Up 100 Mbps Full Duplex" after about 3 seconds,
    stable for the whole 30 seconds

After restoring the default advertisement (0x80000000002f), the link came
back at 2500 Mbps Full Duplex both times. So this port supports 100 Mbps
but not 10 Mbps, which matches your explanation.

I also need to correct my report: I cited FreeBSD bug 282140 as the same
problem. Looking at it again, FreeBSD fixed a different bug there (the
wake filters were never armed), and the PHPM change was dropped after
the reporter's switch turned out to support 10 Mbps. So the bits are the
same, but FreeBSD kept the 10 Mbps behavior.

> In recent years, an increasing number of switches stopped supporting
> 10Mbps, so we have been receiving reports of similar problems from time
> to time.

I think this is still worth addressing in the driver, if possible. As
you said, more and more network hardware no longer supports 10 Mbps, and
with such hardware Wake-on-LAN fails even when it would link at
100 Mbps. If I understand the issue correctly, keeping 100 Mbps
available in D3 as well would make it work with this router, and likely
with others like it.

Thanks,
Michael