public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: <Austin.Bolen@dell.com>
To: <keith.busch@intel.com>, <Austin.Bolen@dell.com>
Cc: <keith.busch@linux.intel.com>, <yi.zhang@redhat.com>,
	<linux-block@vger.kernel.org>, <osandov@osandov.com>,
	<linux-nvme@lists.infradead.org>, <ming.lei@redhat.com>
Subject: Re: blktests block/019 lead system hang
Date: Wed, 13 Jun 2018 17:17:08 +0000	[thread overview]
Message-ID: <4d119d6db0174b39b4e7b0b11ea8d5d1@AUSX13MPC127.AMER.DELL.COM> (raw)
In-Reply-To: 20180613154415.GC5574@localhost.localdomain

On 6/13/2018 10:41 AM, Keith Busch wrote:=0A=
> Thanks for the feedback!=0A=
> This test does indeed toggle the Link Control Link Disable bit to simulat=
e=0A=
> the link failure. The PCIe specification specifically covers this case=0A=
> in Section 3.2.1, Data Link Control and Management State Machine Rules:=
=0A=
>=0A=
>   If the Link Disable bit has been Set by software, then the subsequent=
=0A=
>   transition to DL_Inactive must not be considered an error.=0A=
>=0A=
> So this test should suppress any Suprise Down Error events, but handling=
=0A=
> that particular event wasn't the intent of the test (and as you mentioned=
,=0A=
> it ought not occur anyway since the slot is HP Surprise capable).=0A=
>=0A=
> The test should not suppress reporting the Data Link Layer State Changed=
=0A=
> slot status. And while this doesn't trigger a Slot PDC status, triggering=
=0A=
> a DLLSC should occur since the Link Status DLLLA should go to 0 when=0A=
> state machine goes from DL_Active to DL_Down, regardless of if a Suprise=
=0A=
> Down Error was detected.=0A=
>=0A=
> The Linux PCIEHP driver handles a DLLSC link-down event the same as=0A=
> a presence detect remove event, and that's part of what this test was=0A=
> trying to cover.=0A=
=0A=
Yes, the R730 could mask the error if OS sets Data Link Layer State=0A=
Changed Enable =3D 1 and could let the OS handle the hot-plug event=0A=
similar to what is done for surprise removal.  Current platform policy=0A=
on R730 is to not do that and only suppress errors related to physical=0A=
surprise removal (PDS =3D 0).  We'll probably forgo the option of=0A=
suppressing any non-surprise remove link down errors even if OS sets=0A=
Data Link Layer State Changed Enable =3D 1 and go straight to the=0A=
containment error recovery model for DPC once the architecture is=0A=
finalized to handle these non-surprise remove related error.  In the=0A=
meantime, it is expected (though not ideal) that this family of servers=0A=
will crash for this particular test.  Ditto for the test that disables=0A=
Memory Space Enable bit in the command register.=0A=
=0A=
-Austin=0A=
=0A=
=0A=

  reply	other threads:[~2018-06-13 17:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <838678680.4693215.1527664726174.JavaMail.zimbra@redhat.com>
2018-05-30  7:26 ` blktests block/019 lead system hang Yi Zhang
2018-06-05 16:18   ` Keith Busch
2018-06-05 17:21     ` Keith Busch
2018-06-06  5:42       ` Yi Zhang
2018-06-06 14:28         ` Keith Busch
2018-06-12 23:41     ` Austin.Bolen
2018-06-13 15:44       ` Keith Busch
2018-06-13 17:17         ` Austin.Bolen [this message]
2018-06-13 18:24         ` Austin.Bolen

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=4d119d6db0174b39b4e7b0b11ea8d5d1@AUSX13MPC127.AMER.DELL.COM \
    --to=austin.bolen@dell.com \
    --cc=keith.busch@intel.com \
    --cc=keith.busch@linux.intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=ming.lei@redhat.com \
    --cc=osandov@osandov.com \
    --cc=yi.zhang@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