All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>,
	Greg KH <greg@kroah.com>,
	kernel list <linux-kernel@vger.kernel.org>,
	Joe Lawrence <joe.lawrence@stratus.com>,
	Myron Stowe <myron.stowe@redhat.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"Allan, Bruce W" <bruce.w.allan@intel.com>,
	"Skidmore, Donald C" <donald.c.skidmore@intel.com>,
	"Rose, Gregory V" <gregory.v.rose@intel.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>,
	"Duyck, Alexander H" <alexander.h.duyck@intel.com>,
	"Ronciak, John" <john.ronciak@intel.com>,
	"Dave, Tushar N" <tushar.n.dave@intel.com>,
	"e1000-devel@lists.sourceforge.net" 
	<e1000-devel@lists.sourceforge.net>,
	linux-pci@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
	mjg59@srcf.ucam.org
Subject: Re: /sys/module/pcie_aspm/parameters/policy not writable?
Date: Fri, 12 Jul 2013 13:52:53 +0200	[thread overview]
Message-ID: <20130712115253.GA4585@amd.pavel.ucw.cz> (raw)
In-Reply-To: <20130710225715.GA23171@google.com>

Hi!

> > > 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].
> > 
> > Yes, this is the problem we run into.  It would help if the call to pci_disable_link_state_locked() returned an error if ASPM is not disabled as requested so that drivers can then do the brute force disabling of it themselves.
> 
> I considered returning an error, but resisted because I think drivers
> will just handle the error by doing the brute-force disable themselves,
> and then we might as well drop the pci_disable_link_state() interface
> completely.

What is that? Yes, if function does not perform what it was asked to
do, it should return an error. Anything else is antisocial.

If drivers will attempt to do something _more_ antisocial (like doing
PCI bit banging) we can surely catch it during review.

[Actually, the functions seem to have "force" parameter. Should we
just let e1000e/iwlwifi set the force? They _know_ hardware will not
work properly with the ASPM.] 

> I proposed a patch [3] a while ago that made pci_disable_link_state()
> turn off ASPM unconditionally.  That would have the same effect as
> returning failure and having drivers disable ASPM themselves.  But
> Rafael and Matthew thought it was too risky [4] (and I think they're
> probably right because it does not match the Windows behavior).

Well, I believe "patch might be risky" is trumped by "this ethernet
card is not usable". 

> So by extension, I guess it would also be risky to return an error and
> have the driver disable ASPM.

It does not seem like clean conclusion to me.

Doing force-disabling on selected hardware that needs it (x60+e1000e)
is certainly less risky than changing behaviour for all the 1000
notebooks out there.

So yes, you should be returning error.

At the very least, e1000e and iwlwifi could warn the user loudly and
maybe even disable the interface.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  parent reply	other threads:[~2013-07-12 11:52 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 [this message]
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
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=20130712115253.GA4585@amd.pavel.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=alexander.h.duyck@intel.com \
    --cc=bhelgaas@google.com \
    --cc=bruce.w.allan@intel.com \
    --cc=carolyn.wyborny@intel.com \
    --cc=donald.c.skidmore@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=greg@kroah.com \
    --cc=gregory.v.rose@intel.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=joe.lawrence@stratus.com \
    --cc=john.ronciak@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=myron.stowe@redhat.com \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=rjw@sisk.pl \
    --cc=tushar.n.dave@intel.com \
    /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.