linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
	Aron Griffis <aron@arongriffis.com>,
	linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org
Subject: Re: PCIe unsupported request with Intel 760p
Date: Fri, 11 May 2018 14:02:57 -0600	[thread overview]
Message-ID: <20180511200256.GA7772@localhost.localdomain> (raw)
In-Reply-To: <20180511193923.GJ190385@bhelgaas-glaptop.roam.corp.google.com>

On Fri, May 11, 2018 at 02:39:23PM -0500, Bjorn Helgaas wrote:
> Any update on this?  I'm pretty concerned about this issue because it
> *looks* like we're not doing anything that should cause this problem,
> and I don't know what we *could* do to avoid it.

The only update I have at the moment is that the sighting has been
opened and assigned to the development team. I'm afraid I do not have an
ETA on when we will get a response, much less a fix.
 
> The theory is that the Intel 760p NVMe is sending LTR messages even
> though it's configured to *not* send them.  It happens that Aron's
> system has a root port that doesn't support LTR, and it complains when
> it sees the messages.
> 
> Anybody who has the Intel 760p NVMe should be able to reproduce this.
> If the root port leading to the NVMe doesn't support LTR (its DevCap2
> would say "LTR-"), the same problem should occur.
> 
> If your root port *does* support LTR, you might be able to force this
> to happen by booting with "pcie_aspm=off" and then running this
> command where "bb:dd.f" is the bus/domain/function of the root port:
> 
>   # setpci -sbb:dd.f CAP_EXP+0x28.W=0:0x400
> 
> But I tried this on a root port leading to a different (non-NVMe)
> device with LTR enabled, and I didn't see any AER complaints about
> unexpected LTR messages, so maybe there's something I'm missing.

Hm, do you know if you were able to get the end device to transmit
an LTR while the root port had the capability disabled? Just a quick
glance through the spec suggests it should transmit one if you toggle
the capability off/on.

If the capability is disabled in the root/downstream port, and it
recieves an LTR, it should be treated as an Unsupported Request error.
That should trigger an AER if it's not masked and enabled to report it.

If everything is set up to make the error happen, but you're not seeing
one, it sounds like maybe the message is just getting discarded.

  reply	other threads:[~2018-05-11 20:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKDfzeD5_AV=YtWqTPr=40vvW4oMFAs4gJs_r42PJWcb815zyQ@mail.gmail.com>
2018-05-07 12:30 ` PCIe unsupported request with Intel 760p Aron Griffis
2018-05-07 13:43   ` Matthew Wilcox
2018-05-07 15:12     ` Keith Busch
2018-05-07 15:16       ` Matthew Wilcox
2018-05-07 15:57       ` Aron Griffis
2018-05-07 16:08         ` Keith Busch
2018-05-11 19:39       ` Bjorn Helgaas
2018-05-11 20:02         ` Keith Busch [this message]
2018-05-25 23:20   ` Keith Busch
2018-05-30 23:33     ` Bryan Gurney
2018-07-02 16:36     ` Keith Busch

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=20180511200256.GA7772@localhost.localdomain \
    --to=keith.busch@linux.intel.com \
    --cc=aron@arongriffis.com \
    --cc=helgaas@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=willy@infradead.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).