linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yinghai Lu <yinghai@kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Keith Busch <keith.busch@intel.com>,
	Sinan Kaya <okaya@codeaurora.org>
Subject: Re: [GIT PULL] PCI fixes for v4.10
Date: Sat, 6 May 2017 11:04:08 +0200	[thread overview]
Message-ID: <20170506090408.GA19740@wunner.de> (raw)
In-Reply-To: <20170503180426.GA4058@otc-nc-03>

Hi Ashok,

On Wed, May 03, 2017 at 11:04:28AM -0700, Raj, Ashok wrote:
> attached is recent set of experiments with your patch series applied
> on 4.11 kernel.
> 
> Right after a reboot, poweroff causes an NMI. You can see the message on 
> 1.dmesg. 1.lspci is after reboot, and 2.lspci is after a poweroff/poweron
> sequence.
> 
> You can see there are other differences, like Corrected error enables, 
> and several others.. 

Thanks a lot for carrying out the tests!

It looks like powering the slot off and back on did work - so far so good.

The NMI seems to occur when powering off the slot.  The lspci output shows
that the Ethernet card in the slot signaled an Unsupported Request Error
which it handled as an Advisory Non-Fatal Error.  However the CPER is sent
by the hotplug port, not by the card in the slot.  It's unclear if the root
port is forwarding the error on behalf of the card in the slot or if it
experienced an error itself.  Please also send lspci output for the hotplug
port (0000:5d:00.0) to clarify this.  It would be ideal to also have lspci
output after the slot has been powered off and before it's powered on.

Unfortunately our CPER parser doesn't log the contents of the "AER info"
field.  It would contain the TLP that triggered the error.

Some ideas to understand what's going on:
- Could you test if the NMI also occurs without my pciehp runtime PM series,
  i.e. with a stock v4.11 kernel?
- Could you apply the small debug patch included below and re-test powering
  off/on?  It will log when the root port goes to D3hot or back to D0.
- If you test with a different card in the slot, do you also get an NMI?

There are a few oddities that caught my eye:
- The class code is logged with incorrect byte order.  I've sent out a
  patch yesterday, could you test if it fixes this?
- After calling pciehp_green_led_off(), there are *two* Command Complete
  interrupts from the slot?!
- The Ethernet card's Parity Error Response bit (#6 in Command Register)
  is unset after boot, but set after powering the slot off and back on?!

Thanks,

Lukas

-- >8 --
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 5b638c6..65f3b07 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -421,9 +421,10 @@ static int rpm_idle(struct device *dev, int rpmflags)
 
 	callback = RPM_GET_CALLBACK(dev, runtime_idle);
 
-	if (callback)
+	if (callback) {
+		dev_info(dev, "rpm_idle\n");
 		retval = __rpm_callback(callback, dev);
-
+	}
 	dev->power.idle_notification = false;
 	wake_up_all(&dev->power.wait_queue);
 
@@ -592,6 +593,7 @@ static int rpm_suspend(struct device *dev, int rpmflags)
 	callback = RPM_GET_CALLBACK(dev, runtime_suspend);
 
 	dev_pm_enable_wake_irq_check(dev, true);
+	dev_info(dev, "rpm_suspend\n");
 	retval = rpm_callback(callback, dev);
 	if (retval)
 		goto fail;
@@ -814,6 +816,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
 	callback = RPM_GET_CALLBACK(dev, runtime_resume);
 
 	dev_pm_disable_wake_irq_check(dev);
+	dev_info(dev, "rpm_resume\n");
 	retval = rpm_callback(callback, dev);
 	if (retval) {
 		__update_runtime_status(dev, RPM_SUSPENDED);

  reply	other threads:[~2017-05-06  9:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170208192054.GA31395@bhelgaas-glaptop.roam.corp.google.com>
2017-02-08 19:22 ` [GIT PULL] PCI fixes for v4.10 Bjorn Helgaas
2017-02-09  4:06   ` Lukas Wunner
2017-02-09 15:09     ` Bjorn Helgaas
2017-02-09 18:23       ` Raj, Ashok
2017-02-09 18:46         ` Raj, Ashok
2017-05-02  1:54           ` Lukas Wunner
2017-05-02  2:41             ` Sinan Kaya
2017-05-02 10:49               ` Lukas Wunner
2017-05-02 14:15                 ` Sinan Kaya
2017-05-02 18:48                 ` Bjorn Helgaas
2017-05-03 18:04             ` Raj, Ashok
2017-05-06  9:04               ` Lukas Wunner [this message]
2017-02-09 20:11       ` Bjorn Helgaas
2017-02-10 12:39         ` Rafael J. Wysocki
2017-02-11  2:39         ` Yinghai Lu
2017-02-11  7:13           ` Yinghai Lu
2017-02-12 19:05           ` Lukas Wunner
2017-02-13 12:10             ` Rafael J. Wysocki
2017-02-16 14:51 Bjorn Helgaas
  -- strict thread matches above, loose matches on Subject: below --
2017-02-02 16:18 Bjorn Helgaas
2017-02-02 16:30 ` Christoph Hellwig
2017-02-02 16:46   ` Bjorn Helgaas
2017-01-19 14:27 Bjorn Helgaas

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=20170506090408.GA19740@wunner.de \
    --to=lukas@wunner.de \
    --cc=ashok.raj@intel.com \
    --cc=helgaas@kernel.org \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=okaya@codeaurora.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=yinghai@kernel.org \
    /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).