netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nix <nix@esperi.org.uk>
To: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: davem@davemloft.net, Chris Boot <bootc@bootc.net>,
	netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
	"Wyborny\, Carolyn" <carolyn.wyborny@intel.com>
Subject: Re: [net-next 5/9] e1000e: Disable ASPM L1 on 82574
Date: Thu, 03 May 2012 11:08:43 +0100	[thread overview]
Message-ID: <87d36ld1as.fsf@spindle.srvr.nix> (raw)
In-Reply-To: <1336038992-3144-6-git-send-email-jeffrey.t.kirsher@intel.com> (Jeff Kirsher's message of "Thu, 3 May 2012 02:56:28 -0700")

On 3 May 2012, Jeff Kirsher spake thusly:

> From: Chris Boot <bootc@bootc.net>
>
> ASPM on the 82574 causes trouble. Currently the driver disables L0s for
> this NIC but only disables L1 if the MTU is >1500. This patch simply
> causes L1 to be disabled regardless of the MTU setting.
>
> Signed-off-by: Chris Boot <bootc@bootc.net>
> Cc: "Wyborny, Carolyn" <carolyn.wyborny@intel.com>
> Cc: Nix <nix@esperi.org.uk>
> Link: https://lkml.org/lkml/2012/3/19/362
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

(reminder: this is known not to fix the instance of this problem I am
experiencing, where ASPM is being re-enabled by something even if turned
off via setpci during boot, though it does fix those instances seen by
others where that doesn't happen. I'd have done more printf()-scattering
debugging to see where it's turned back on if it wasn't that this is
happening on an always-on server for which rebooting outside the dead of
night is a long-winded chore...)

FWIW I have also seen -- very rare -- lockups of the same nature on
82574L links in 100MbE mode using non-jumbo frames. However they are far
more common on GbE jumbo-framed links, normally taking less than an hour
to take the link down with a wildly corrupted register set (as shown by
ethtool).

(It's annoying this firmware isn't flashable so we could just *fix* this
bug rather than working around it. :( )


I think I might cheat a bit next and printk_once() the state of ASPM L1
on the errant PCI device from inside the scheduler when it flips from L1
off to L1 on again. At 100 tests per second that should indicate at what
time the thing is turned back on fairly tightly: even if not providing a
direct clue as to which bit of the kernel is doing it, if I combine it
with a set -x in userspace it should at least indicate what bit of the
boot process is happening at the same time. It'll be the weekend before
I can try that though.

-- 
NULL && (void)

  reply	other threads:[~2012-05-03 10:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-03  9:56 [net-next 0/9][pull request] Intel Wired LAN Dirver Updates Jeff Kirsher
2012-05-03  9:56 ` [net-next 1/9] e1000e: suggest a possible workaround to a device hang on 82577/8 Jeff Kirsher
2012-05-03  9:56 ` [net-next 2/9] e1000e: cleanup long [read|write]_reg_locked PHY ops function pointers Jeff Kirsher
2012-05-03  9:56 ` [net-next 3/9] e1000e: Resolve intermittent negotiation issue on 82574/82583 Jeff Kirsher
2012-05-03  9:56 ` [net-next 4/9] e1000e: Driver workaround for IPv6 Header Extension Erratum Jeff Kirsher
2012-05-03  9:56 ` [net-next 5/9] e1000e: Disable ASPM L1 on 82574 Jeff Kirsher
2012-05-03 10:08   ` Nix [this message]
2012-05-03 20:12     ` Wyborny, Carolyn
2012-05-03 20:17       ` Nix
2012-05-05 16:33         ` Nix
2012-05-09 14:02           ` Nix
2012-05-03  9:56 ` [net-next 6/9] e1000e: Remove special case for 82573/82574 ASPM L1 disablement Jeff Kirsher
2012-05-03  9:56 ` [net-next 7/9] ixgbevf: Add support to recognize 100mb link speed Jeff Kirsher
2012-05-03  9:56 ` [net-next 8/9] ixgbevf: Make sure jumbo frames are set correctly after PF reset Jeff Kirsher
2012-05-03  9:56 ` [net-next 9/9] ixgbevf: Update version string Jeff Kirsher
2012-05-03 17:30 ` [net-next 0/9][pull request] Intel Wired LAN Dirver Updates David Miller

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=87d36ld1as.fsf@spindle.srvr.nix \
    --to=nix@esperi.org.uk \
    --cc=bootc@bootc.net \
    --cc=carolyn.wyborny@intel.com \
    --cc=davem@davemloft.net \
    --cc=gospo@redhat.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=sassmann@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).