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
signature.asc
Description: PGP signature
