[Intel-wired-lan] PCI Advanced Features (especially FLR) missing in several newer Intel integrated ethernet devices

[Intel-wired-lan] PCI Advanced Features (especially FLR) missing in several newer Intel integrated ethernet devices

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]

Hi,

I've got already at least 3 reports about e1000e device that is missing
FLR (which makes it harder to passthrough to a VM, among other things).
Interestingly, when looking at config space, the capability appears to
be there, just isn't linked to the list. For example:

    sudo lspci -nnvxxxs 00:1f.6
    00:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:57a1]
        Subsystem: Lenovo Device [17aa:512b]
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at ab700000 (32-bit, non-prefetchable) [size=128K]
        Capabilities: [c8] Power Management version 3
        Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Kernel driver in use: pciback
        Kernel modules: e1000e
    00: 86 80 a1 57 06 04 10 00 00 00 00 02 00 00 00 00
    10: 00 00 70 ab 00 00 00 00 00 00 00 00 00 00 00 00
    20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 2b 51
    30: 00 00 00 00 c8 00 00 00 00 00 00 00 ff 04 00 00
    40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    80: 28 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00
    90: 00 00 00 00 1f 00 00 00 00 00 00 00 00 00 00 00
    a0: ff ff ff ff ff ff ff ff 03 10 03 10 00 00 00 00
    b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    c0: 00 00 00 00 00 00 00 00 01 d0 23 c8 08 20 00 00
    d0: 05 00 81 00 b8 12 e0 fe 00 00 00 00 00 00 00 00
    e0: 13 00 06 03 00 00 00 00 00 00 00 00 00 00 00 00
    f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

As you can see, the "PCI Advanced Features" is not listed. But, if you
traverse the list manually, you can see that the capability is there at
0xe0 - it just isn't linked at 0xd1 (0xd1 has 0x00 instead of 0xe0). And
it appears it isn't just coincidence:
 - 0x03 at 0xe3 says FLR is supported (bit FLR_CAP is set)
 - writing 0x01 to 0xe4 (INITIATE_FLR) does appear to reset the device

It's even possible to link the capability manually (write 0xe0 to 0xd1)
and then Linux is happy to use it via the standard `echo 1 >
/sys/devices/.../reset` interface (but, ofc, such linking doesn't
survive the reset).

Based on reports I've received, it applies at least to devices with the
following VID:DID:
- 8086:550a
- 8086:57a1
- 8086:57a0

Some of those reports at https://github.com/QubesOS/qubes-issues/issues/10657

My question is: why the capability is not linked? Does it want a fix in
firmware? Or maybe a quirk in the kernel to restore working FLR?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Intel-wired-lan] PCI Advanced Features (especially FLR) missing in several newer Intel integrated ethernet devices

[Ruinskiy, Dima]

On 23/02/2026 17:33, Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I've got already at least 3 reports about e1000e device that is missing
> FLR (which makes it harder to passthrough to a VM, among other things).
> Interestingly, when looking at config space, the capability appears to
> be there, just isn't linked to the list. For example:
> 
>      sudo lspci -nnvxxxs 00:1f.6
>      00:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:57a1]
>          Subsystem: Lenovo Device [17aa:512b]
>          Flags: bus master, fast devsel, latency 0, IRQ 19
>          Memory at ab700000 (32-bit, non-prefetchable) [size=128K]
>          Capabilities: [c8] Power Management version 3
>          Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
>          Kernel driver in use: pciback
>          Kernel modules: e1000e
>      00: 86 80 a1 57 06 04 10 00 00 00 00 02 00 00 00 00
>      10: 00 00 70 ab 00 00 00 00 00 00 00 00 00 00 00 00
>      20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 2b 51
>      30: 00 00 00 00 c8 00 00 00 00 00 00 00 ff 04 00 00
>      40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      80: 28 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00
>      90: 00 00 00 00 1f 00 00 00 00 00 00 00 00 00 00 00
>      a0: ff ff ff ff ff ff ff ff 03 10 03 10 00 00 00 00
>      b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>      c0: 00 00 00 00 00 00 00 00 01 d0 23 c8 08 20 00 00
>      d0: 05 00 81 00 b8 12 e0 fe 00 00 00 00 00 00 00 00
>      e0: 13 00 06 03 00 00 00 00 00 00 00 00 00 00 00 00
>      f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> As you can see, the "PCI Advanced Features" is not listed. But, if you
> traverse the list manually, you can see that the capability is there at
> 0xe0 - it just isn't linked at 0xd1 (0xd1 has 0x00 instead of 0xe0). And
> it appears it isn't just coincidence:
>   - 0x03 at 0xe3 says FLR is supported (bit FLR_CAP is set)
>   - writing 0x01 to 0xe4 (INITIATE_FLR) does appear to reset the device
> 
> It's even possible to link the capability manually (write 0xe0 to 0xd1)
> and then Linux is happy to use it via the standard `echo 1 >
> /sys/devices/.../reset` interface (but, ofc, such linking doesn't
> survive the reset).
> 
> Based on reports I've received, it applies at least to devices with the
> following VID:DID:
> - 8086:550a
> - 8086:57a1
> - 8086:57a0
> 
> Some of those reports at https://github.com/QubesOS/qubes-issues/issues/10657
> 
> My question is: why the capability is not linked? Does it want a fix in
> firmware? Or maybe a quirk in the kernel to restore working FLR?
> 

Hi Marek,

The FLR capability not linked is intentional - ICH8-based e1000e devices 
have issues with it. While it may sometimes work, in other cases it can 
put the LAN controller into a broken state only recoverable by a hard reset.

Some previous e1000e devices (0x1502, 0x1503) exposed it properly via 
the linked list pointers, and this caused the above issues, therefore a 
quirk was issued to avoid using it 
(https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5618).

For later devices (I217/I218/I219 generations) it was removed from the 
linked list so that the OS does not find / attempt to use it.

It would probably be better if it was completely cleaned from the config 
space, because your test (and mine) shows that if someone ignores the 
linked list and triggers FLR manually - it still affects the hardware, 
which may lead to unpredictable outcomes. I will inquire about it.

AFAIK, the recommended alternative to achieve an FLR-equivalent reset on 
these devices is D0-->D3-->D0.

--Dima

Re: [Intel-wired-lan] PCI Advanced Features (especially FLR) missing in several newer Intel integrated ethernet devices

[Marek Marczykowski-Górecki]

[-- Attachment #1: Type: text/plain, Size: 5933 bytes --]

On Tue, Feb 24, 2026 at 01:47:22PM +0200, Ruinskiy, Dima wrote:
> On 23/02/2026 17:33, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > I've got already at least 3 reports about e1000e device that is missing
> > FLR (which makes it harder to passthrough to a VM, among other things).
> > Interestingly, when looking at config space, the capability appears to
> > be there, just isn't linked to the list. For example:
> > 
> >      sudo lspci -nnvxxxs 00:1f.6
> >      00:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:57a1]
> >          Subsystem: Lenovo Device [17aa:512b]
> >          Flags: bus master, fast devsel, latency 0, IRQ 19
> >          Memory at ab700000 (32-bit, non-prefetchable) [size=128K]
> >          Capabilities: [c8] Power Management version 3
> >          Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> >          Kernel driver in use: pciback
> >          Kernel modules: e1000e
> >      00: 86 80 a1 57 06 04 10 00 00 00 00 02 00 00 00 00
> >      10: 00 00 70 ab 00 00 00 00 00 00 00 00 00 00 00 00
> >      20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 2b 51
> >      30: 00 00 00 00 c8 00 00 00 00 00 00 00 ff 04 00 00
> >      40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >      50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >      60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >      70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >      80: 28 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00
> >      90: 00 00 00 00 1f 00 00 00 00 00 00 00 00 00 00 00
> >      a0: ff ff ff ff ff ff ff ff 03 10 03 10 00 00 00 00
> >      b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >      c0: 00 00 00 00 00 00 00 00 01 d0 23 c8 08 20 00 00
> >      d0: 05 00 81 00 b8 12 e0 fe 00 00 00 00 00 00 00 00
> >      e0: 13 00 06 03 00 00 00 00 00 00 00 00 00 00 00 00
> >      f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 
> > As you can see, the "PCI Advanced Features" is not listed. But, if you
> > traverse the list manually, you can see that the capability is there at
> > 0xe0 - it just isn't linked at 0xd1 (0xd1 has 0x00 instead of 0xe0). And
> > it appears it isn't just coincidence:
> >   - 0x03 at 0xe3 says FLR is supported (bit FLR_CAP is set)
> >   - writing 0x01 to 0xe4 (INITIATE_FLR) does appear to reset the device
> > 
> > It's even possible to link the capability manually (write 0xe0 to 0xd1)
> > and then Linux is happy to use it via the standard `echo 1 >
> > /sys/devices/.../reset` interface (but, ofc, such linking doesn't
> > survive the reset).
> > 
> > Based on reports I've received, it applies at least to devices with the
> > following VID:DID:
> > - 8086:550a
> > - 8086:57a1
> > - 8086:57a0
> > 
> > Some of those reports at https://github.com/QubesOS/qubes-issues/issues/10657
> > 
> > My question is: why the capability is not linked? Does it want a fix in
> > firmware? Or maybe a quirk in the kernel to restore working FLR?
> > 
> 
> Hi Marek,
> 
> The FLR capability not linked is intentional - ICH8-based e1000e devices
> have issues with it. While it may sometimes work, in other cases it can put
> the LAN controller into a broken state only recoverable by a hard reset.
> 
> Some previous e1000e devices (0x1502, 0x1503) exposed it properly via the
> linked list pointers, and this caused the above issues, therefore a quirk
> was issued to avoid using it
> (https://github.com/torvalds/linux/blob/master/drivers/pci/quirks.c#L5618).
> 
> For later devices (I217/I218/I219 generations) it was removed from the
> linked list so that the OS does not find / attempt to use it.
> 
> It would probably be better if it was completely cleaned from the config
> space, because your test (and mine) shows that if someone ignores the linked
> list and triggers FLR manually - it still affects the hardware, which may
> lead to unpredictable outcomes. I will inquire about it.

Thanks for the context.

> AFAIK, the recommended alternative to achieve an FLR-equivalent reset on
> these devices is D0-->D3-->D0.

Unfortunately, Linux doesn't want to do that either:
	Capabilities: [c8] Power Management version 3
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-

The NoSoftRst+ flag is set, and this makes pci_pm_reset() to skip this
method:

    /**
     * pci_pm_reset - Put device into PCI_D3 and back into PCI_D0.
     * @dev: Device to reset.
     * @probe: if true, return 0 if the device can be reset this way.
     *
     * If @dev supports native PCI PM and its PCI_PM_CTRL_NO_SOFT_RESET flag is
     * unset, it will be reinitialized internally when going from PCI_D3hot to
     * PCI_D0.  If that's the case and the device is not in a low-power state
     * already, force it into PCI_D3hot and back to PCI_D0, causing it to be reset.
     *
     * NOTE: This causes the caller to sleep for twice the device power transition
     * cooldown period, which for the D0->D3hot and D3hot->D0 transitions is 10 ms
     * by default (i.e. unless the @dev's d3hot_delay field has a different value).
     * Moreover, only devices in D0 can be reset by this function.
     */
    static int pci_pm_reset(struct pci_dev *dev, bool probe)
    {
        u16 csr;
        int ret;

        if (!dev->pm_cap || dev->dev_flags & PCI_DEV_FLAGS_NO_PM_RESET)
            return -ENOTTY;

        pci_read_config_word(dev, dev->pm_cap + PCI_PM_CTRL, &csr);
        if (csr & PCI_PM_CTRL_NO_SOFT_RESET)
            return -ENOTTY;

Is that flag set a mistake? Or maybe this method doesn't work either?
Note the device is presented as function 6 of a multi-function device
(together with audio device, SPI controller and few others)... 

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]