All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: "Ruinskiy, Dima" <dima.ruinskiy@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Subject: Re: [Intel-wired-lan] PCI Advanced Features (especially FLR) missing in several newer Intel integrated ethernet devices
Date: Tue, 24 Feb 2026 13:35:24 +0100	[thread overview]
Message-ID: <aZ2bDRpx1SuiwitX@mail-itl> (raw)
In-Reply-To: <99f696b8-75ef-43bb-8220-6073ae90aea4@intel.com>

[-- 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 --]

      reply	other threads:[~2026-02-24 12:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23 15:33 [Intel-wired-lan] PCI Advanced Features (especially FLR) missing in several newer Intel integrated ethernet devices Marek Marczykowski-Górecki
2026-02-24 11:47 ` Ruinskiy, Dima
2026-02-24 12:35   ` Marek Marczykowski-Górecki [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZ2bDRpx1SuiwitX@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=dima.ruinskiy@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.