All of lore.kernel.org
 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: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-09  1:26 /sys/module/pcie_aspm/parameters/policy not writable? 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-10 22:57                 ` Bjorn Helgaas
2013-07-11 17:45                 ` Wyborny, Carolyn
2013-07-11 17:45                   ` Wyborny, Carolyn
2013-07-12 11:52                 ` Pavel Machek
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 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.