lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200529192143.GA448525@bjorn-Precision-5520>
Date:   Fri, 29 May 2020 14:21:43 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Bjorn Helgaas <bhelgaas@...gle.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org
Subject: Re: Lost PCIe PME after a914ff2d78ce ("PCI/ASPM: Don't select
 CONFIG_PCIEASPM by default")

[+cc Rafael, linux-kernel]

On Fri, May 29, 2020 at 08:50:46PM +0200, Heiner Kallweit wrote:
> On 28.05.2020 23:44, Heiner Kallweit wrote:
> > For whatever reason with this change (and losing ASPM control) I also
> > loose the PCIe PME interrupts. This prevents my network card from
> > resuming from runtime-suspend.
> > Reverting the change brings back ASPM control and the PCIe PME irq's.
> > 
> > Affected system is a Zotac MiniPC with a N3450 CPU:
> > PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb)
> > 
> I checked a little bit further and w/o ASPM control the root ports
> don't have the PME service bit set in their capabilities.
> Not sure whether this is a chipset bug or whether there's a better
> explanation. However more chipsets may have such a behavior.

Hmm.  Is the difference simply changing the PCIEASPM config symbol, or
are you booting with command-line arguments like "pcie_aspm=off"?

What's the specific PME bit that changes in the root ports?  Can you
collect the "sudo lspci -vvxxxx" output with and without ASPM?

The capability bits are generally read-only as far as the PCI spec is
concerned, but devices have implementation-specific knobs that the
BIOS may use to change things.  Without CONFIG_PCIEASPM, Linux will
not request control of LTR, and that could cause the BIOS to change
something.  You should be able to see the LTR control difference in
the dmesg logging about _OSC.

> W/o the "default y" for ASPM control we also have the situation now
> that the config option description says "When in doubt, say Y."
> but it takes the EXPERT mode to enable it. This seems to be a little
> bit inconsistent.

We should probably remove the "if EXPERT" from the PCIEASPM kconfig.
But I would expect PME to work correctly regardless of PCIEASPM, so
removing "if EXPERT" doesn't solve the underlying problem.

Rafael, does this ring any bells for you?  I don't remember a
connection between PME and ASPM, but maybe there is one.

> To cut a long story short:
> At least on some systems this change has unwanted side effects.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ