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

Reply via email to