All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@linux.intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Aron Griffis <aron@arongriffis.com>,
	linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org
Subject: Re: PCIe unsupported request with Intel 760p
Date: Mon, 7 May 2018 09:12:47 -0600	[thread overview]
Message-ID: <20180507151246.GB20686@localhost.localdomain> (raw)
In-Reply-To: <20180507134354.GF18116@bombadil.infradead.org>

On Mon, May 07, 2018 at 06:43:54AM -0700, Matthew Wilcox wrote:
> On Mon, May 07, 2018 at 08:30:35AM -0400, Aron Griffis wrote:
> > 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.
> 
> Decoding this further, the Requester ID is 70:00.0 (ie the NVMe device is
> sending the LTR message) so the Root Port is the one saying "Unsupported
> Request".  Which is fair enough, because ...
> 
> > 00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #9 (rev f0) (prog-if 00 [Normal decode])
> > 	Bus: primary=00, secondary=70, subordinate=70, sec-latency=0
> > 		DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd+
> > 			 AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS-
> > 		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
> > 			 AtomicOpsCtl: ReqEn- EgressBlck-
> 
> the Root Port doesn't know what LTR is.
> 
> > 70:00.0 Non-Volatile memory controller: Intel Corporation Device f1a6 (rev 03) (prog-if 02 [NVM Express])
> > 	Capabilities: [70] Express (v2) Endpoint, MSI 00
> > 		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
> > 			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
> > 		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
> > 			 AtomicOpsCtl: ReqEn-
> 
> The device *does* know what LTR is, but it's supposed to be disabled.
> 
> Is there more recent firmware for this device?

Hi Willy,

Thank you for the detailed analysis. :)

I'm not familiar with this device, but I'll check internally to see if
this a later firmware release address this.

Aron,
Could you let me know the firmware revision you're currently running?

Thanks,
Keith

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

WARNING: multiple messages have this Message-ID (diff)
From: keith.busch@linux.intel.com (Keith Busch)
Subject: PCIe unsupported request with Intel 760p
Date: Mon, 7 May 2018 09:12:47 -0600	[thread overview]
Message-ID: <20180507151246.GB20686@localhost.localdomain> (raw)
In-Reply-To: <20180507134354.GF18116@bombadil.infradead.org>

On Mon, May 07, 2018@06:43:54AM -0700, Matthew Wilcox wrote:
> On Mon, May 07, 2018@08:30:35AM -0400, Aron Griffis wrote:
> > 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.
> 
> Decoding this further, the Requester ID is 70:00.0 (ie the NVMe device is
> sending the LTR message) so the Root Port is the one saying "Unsupported
> Request".  Which is fair enough, because ...
> 
> > 00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port #9 (rev f0) (prog-if 00 [Normal decode])
> > 	Bus: primary=00, secondary=70, subordinate=70, sec-latency=0
> > 		DevCap2: Completion Timeout: Range ABC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd+
> > 			 AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS-
> > 		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
> > 			 AtomicOpsCtl: ReqEn- EgressBlck-
> 
> the Root Port doesn't know what LTR is.
> 
> > 70:00.0 Non-Volatile memory controller: Intel Corporation Device f1a6 (rev 03) (prog-if 02 [NVM Express])
> > 	Capabilities: [70] Express (v2) Endpoint, MSI 00
> > 		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
> > 			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
> > 		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
> > 			 AtomicOpsCtl: ReqEn-
> 
> The device *does* know what LTR is, but it's supposed to be disabled.
> 
> Is there more recent firmware for this device?

Hi Willy,

Thank you for the detailed analysis. :)

I'm not familiar with this device, but I'll check internally to see if
this a later firmware release address this.

Aron,
Could you let me know the firmware revision you're currently running?

Thanks,
Keith

  reply	other threads:[~2018-05-07 15:12 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 [this message]
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
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=20180507151246.GB20686@localhost.localdomain \
    --to=keith.busch@linux.intel.com \
    --cc=aron@arongriffis.com \
    --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 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.