mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Pavel Machek <pavel@ucw.cz>, Greg KH <greg@kroah.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Joe Lawrence <joe.lawrence@stratus.com>,
	Myron Stowe <myron.stowe@redhat.com>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Bruce Allan <bruce.w.allan@intel.com>,
	"e1000-devel@lists.sourceforge.net" 
	<e1000-devel@lists.sourceforge.net>
Subject: Re: /sys/module/pcie_aspm/parameters/policy not writable?
Date: Wed, 31 Jul 2013 23:19:36 -0700	[thread overview]
Message-ID: <1375337976.2877.63.camel@jtkirshe-mobl> (raw)
In-Reply-To: <CAErSpo5ig3bxZ3hBUUrzTdc=YqHy7cBGBxOLru4NYdyOOR+W5w@mail.gmail.com>

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

On Wed, 2013-07-10 at 13:57 -0600, Bjorn Helgaas wrote:
> [+cc Jeff, Jesse, et al, e1000-devel]
> 
> Holy cow, you guys have a lot of folks listed in MAINTAINERS for Intel
> drivers :)  This is an ASPM question, if that helps narrow down the
> folks interested.

Bruce Allan is the e1000e maintainer, I have trimmed down the
recipients.  If you simply add e1000-devel mailing list, that will get
to all of us and we can respond accordingly.

I need to put together a patch to remove PJ because he is no longer in
our group.

> 
> On Wed, Jul 10, 2013 at 7:29 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> >> But:
> >> >> 1) it should not list unavailable options
> >> >>
> >> >> 2) operation not permitted seems like wrong error code for
> >> >> operation not supported.
> >> >
> >> > So I forcibly enabled ASPM, and now ping latencies are in normal
> >> > range... no matter how I set
> >> > /sys/module/pcie_aspm/parameters/policy. Strange.
> >> >
> >> > Any ideas what correct solution is?
> >> >                                                                         Pavel
> >> > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> >> > (but don't apply)
> > ...
> >> > diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> >> > index e4b1fb2..9a1b63e 100644
> >> > --- a/drivers/pci/pci-acpi.c
> >> > +++ b/drivers/pci/pci-acpi.c
> >> > @@ -382,7 +382,7 @@ static int __init acpi_pci_init(void)
> >> >
> >> >         if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {
> >> >                 printk(KERN_INFO"ACPI FADT declares the system doesn't support PCIe ASPM, so disable it\n");
> >> > -               pcie_no_aspm();
> >> > +//             pcie_no_aspm();
> >> >         }
> >> >
> >> >         ret = register_acpi_bus_type(&acpi_pci_bus);
> >>
> >> Hi Pavel,
> >>
> >> Interesting.  Can you collect dmesg and "lspci -vvv" output for both
> >> cases (high ping latency and normal ping latency)?
> >
> > Will do. Results are in attachment (200KB...)
> >
> >> Also, how much
> >> difference does this make in ping latency?
> >
> > The ping latency goes from 100msec range to <2msec.
> >
> >> If ASPM is enabled for a
> >> device, e.g., your NIC, the link may be put in a low power state when
> >> the device is idle.  It takes time to exit that low power state, of
> >> course, but I would expect that time to be in the microsecond time and
> >> probably not observable via ping.
> >
> > I'd hope so. 100msec ping makes ssh unpleasant to use.
> 
> Pavel's ThinkPad X60 has two NICs: Intel 82573L and Intel PRO/Wireless
> 3945ABG.  I'm pretty sure the problem he's reporting is with the
> 82573L.  Ping times are bad (~100msec) when ASPM is enabled, as
> reported by lspci.
> 
> On Pavel's system, the FADT says we shouldn't enable OSPM control of
> ASPM (ACPI_FADT_NO_ASPM is set), so we set "aspm_disabled = 1".  One
> effect is that we don't blacklist the pre-1.1 82573L device, which I
> think results in it being left with the BIOS configuration, which
> apparently has ASPM enabled.  (Pavel, could you confirm the BIOS
> config, e.g., with "pci=earlydump"?)
> 
> e1000e claims to disable ASPM, but because aspm_disabled is set, the
> driver's call to pci_disable_link_state_locked() actually does nothing
> [1].
> 
> I experimented [2] with Windows and found that when a driver requests
> PciASPMOptOut, Windows will not touch ASPM config if the _OSC method
> fails, i.e., the BIOS declines to grant ASPM control to the OS.
> However, I do not know if Windows similarly ignores PciASPMOptOut when
> the FADT ACPI_FADT_NO_ASPM bit is set.
> 
> The PCI core has failed spectacularly at providing useful ASPM
> interfaces.  Do you Intel folks have any suggestions about how to
> resolve this?  I assume that the Windows driver for the 82573L must
> disable ASPM somehow, even though ACPI_FADT_NO_ASPM is set.  Does it
> just use brute-force, as in the version of __e1000e_disable_aspm()
> that's used when CONFIG_PCIEASPM is not set?
> 
> Bjorn
> 
> [1] We just merged 2add0ec1, which adds a "can't disable ASPM; OS
> doesn't have ASPM control" message in this case, but I don't think
> Pavel's kernel has this change.  It doesn't change the behavior
> anyway.
> 
> [2] https://bugzilla.kernel.org/show_bug.cgi?id=57331



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2013-08-01  6:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-09  1:26 Pavel Machek
2013-07-09  4:13 ` Greg KH
2013-07-09  9:14   ` Pavel Machek
2013-07-09  9:49   ` Pavel Machek
2013-07-09 10:10     ` Pavel Machek
2013-07-09 16:25       ` Bjorn Helgaas
2013-07-10 13:29         ` Pavel Machek
2013-07-10 19:57           ` Bjorn Helgaas
2013-07-10 22:21             ` Wyborny, Carolyn
2013-07-10 22:57               ` Bjorn Helgaas
2013-07-11 17:45                 ` Wyborny, Carolyn
2013-07-12 11:52                 ` Pavel Machek
2013-07-12 11:03             ` Pavel Machek
2013-07-12 11:11             ` Pavel Machek
2013-07-19 17:46               ` Bjorn Helgaas
2013-07-24 15:19                 ` Wyborny, Carolyn
2013-07-28 13:51                   ` Pavel Machek
2013-08-01 14:55                     ` Wyborny, Carolyn
2013-08-01 15:55                     ` Wyborny, Carolyn
2013-08-02  0:39                       ` Pavel Machek
2013-08-02 14:58                         ` Wyborny, Carolyn
2013-07-31 23:53                 ` Bjorn Helgaas
2013-08-01 14:57                   ` Wyborny, Carolyn
2013-08-01 19:33                     ` Bjorn Helgaas
2013-08-01 20:00                   ` Pavel Machek
2013-08-01 20:27                     ` Bjorn Helgaas
2013-08-02  1:02                       ` Pavel Machek
2013-08-02  2:13                       ` Pavel Machek
2013-08-02 13:48                         ` Bjorn Helgaas
2013-08-01  6:19             ` Jeff Kirsher [this message]
2013-07-09 16:37     ` Greg KH
2013-07-09 17:15       ` Pavel Machek
2013-07-10  4:24     ` Robert Hancock

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=1375337976.2877.63.camel@jtkirshe-mobl \
    --to=jeffrey.t.kirsher@intel.com \
    --cc=bhelgaas@google.com \
    --cc=bruce.w.allan@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=greg@kroah.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=joe.lawrence@stratus.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=myron.stowe@redhat.com \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome