From: keith.busch@linux.intel.com (Keith Busch)
Subject: PCIe unsupported request with Intel 760p
Date: Fri, 25 May 2018 17:20:10 -0600 [thread overview]
Message-ID: <20180525232009.GV11037@localhost.localdomain> (raw)
In-Reply-To: <20180507123035.GA20097@gmail.com>
On Mon, May 07, 2018@08:30:35AM -0400, Aron Griffis wrote:
> (Reposting to fix line wrapping, and cc'ing linux-pci at Bjorn's request.)
>
> I'm getting this error continuously with an Intel 760p on 4.16.5 (Fedora 28)
>
> pcieport 0000:00:1d.0: AER: Uncorrected (Non-Fatal) error received: id=00e8
> pcieport 0000:00:1d.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=00e8(Requester ID)
> pcieport 0000:00:1d.0: device [8086:a298] error status/mask=00100000/00010000
> pcieport 0000:00:1d.0: [20] Unsupported Request (First)
> pcieport 0000:00:1d.0: TLP Header: 34000000 70000010 00000000 88468846
> pcieport 0000:00:1d.0: broadcast error_detected message
> pcieport 0000:00:1d.0: broadcast mmio_enabled message
> pcieport 0000:00:1d.0: broadcast resume message
> pcieport 0000:00:1d.0: AER: Device recovery successful
>
> Willy graciously decoded this for me to a "Latency Tolerance Reporting
> Message," and suggested I send email to this list to check whether it's a
> problem with the device or driver.
>
> lspci and full dmesg follow. Please let me know if something else would be
> helpful.
I have some information back from the development team to share. They
believe this may be a hardware errata and are investigating a firmware
side fix.
In the meantime, they think there may be other ways to work around this,
if these are acceptable. Specifically, disabling any non-operational
link states may make this go away, and adding kernel parameter
"pcie_aspm=off" should achieve that.
WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <keith.busch@linux.intel.com>
To: Aron Griffis <aron@arongriffis.com>
Cc: linux-pci@vger.kernel.org, willy@infradead.org,
linux-nvme@lists.infradead.org
Subject: Re: PCIe unsupported request with Intel 760p
Date: Fri, 25 May 2018 17:20:10 -0600 [thread overview]
Message-ID: <20180525232009.GV11037@localhost.localdomain> (raw)
In-Reply-To: <20180507123035.GA20097@gmail.com>
On Mon, May 07, 2018 at 08:30:35AM -0400, Aron Griffis wrote:
> (Reposting to fix line wrapping, and cc'ing linux-pci at Bjorn's request.)
>
> I'm getting this error continuously with an Intel 760p on 4.16.5 (Fedora 28)
>
> pcieport 0000:00:1d.0: AER: Uncorrected (Non-Fatal) error received: id=00e8
> pcieport 0000:00:1d.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, id=00e8(Requester ID)
> pcieport 0000:00:1d.0: device [8086:a298] error status/mask=00100000/00010000
> pcieport 0000:00:1d.0: [20] Unsupported Request (First)
> pcieport 0000:00:1d.0: TLP Header: 34000000 70000010 00000000 88468846
> pcieport 0000:00:1d.0: broadcast error_detected message
> pcieport 0000:00:1d.0: broadcast mmio_enabled message
> pcieport 0000:00:1d.0: broadcast resume message
> pcieport 0000:00:1d.0: AER: Device recovery successful
>
> Willy graciously decoded this for me to a "Latency Tolerance Reporting
> Message," and suggested I send email to this list to check whether it's a
> problem with the device or driver.
>
> lspci and full dmesg follow. Please let me know if something else would be
> helpful.
I have some information back from the development team to share. They
believe this may be a hardware errata and are investigating a firmware
side fix.
In the meantime, they think there may be other ways to work around this,
if these are acceptable. Specifically, disabling any non-operational
link states may make this go away, and adding kernel parameter
"pcie_aspm=off" should achieve that.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2018-05-25 23:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-05 18:25 PCIe unsupported request with Intel 760p Aron Griffis
2018-05-07 12:30 ` Aron Griffis
2018-05-07 12:30 ` Aron Griffis
2018-05-07 13:43 ` Matthew Wilcox
2018-05-07 13:43 ` Matthew Wilcox
2018-05-07 15:12 ` Keith Busch
2018-05-07 15:12 ` Keith Busch
2018-05-07 15:16 ` Matthew Wilcox
2018-05-07 15:16 ` Matthew Wilcox
2018-05-07 15:57 ` Aron Griffis
2018-05-07 15:57 ` Aron Griffis
2018-05-07 16:08 ` Keith Busch
2018-05-07 16:08 ` Keith Busch
2018-05-11 19:39 ` Bjorn Helgaas
2018-05-11 19:39 ` Bjorn Helgaas
2018-05-11 20:02 ` Keith Busch
2018-05-11 20:02 ` Keith Busch
2018-05-25 23:20 ` Keith Busch [this message]
2018-05-25 23:20 ` Keith Busch
2018-05-30 23:33 ` Bryan Gurney
2018-05-30 23:33 ` Bryan Gurney
2018-07-02 16:36 ` Keith Busch
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=20180525232009.GV11037@localhost.localdomain \
--to=keith.busch@linux.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.