From: Bjorn Helgaas <helgaas@kernel.org>
To: "Ziyou Wang (Lenovo)" <ziyou.dev@foxmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Lukas Wunner <lukas@wunner.de>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] PCI/DPC: Increase recovery timeout to 60 seconds
Date: Fri, 6 Nov 2026 09:21:43 -0600 [thread overview]
Message-ID: <20261106152143.GA1621130@bhelgaas> (raw)
In-Reply-To: <tencent_BB887B4DB8D2131AF5026893E0FE567D6D05@qq.com>
On Fri, Nov 06, 2026 at 04:56:55PM +0800, Ziyou Wang (Lenovo) wrote:
> Some NVMe devices need more than 5 seconds to recover after DPC
> containment, but pci_dpc_recovered() waits only 4 seconds. If the device
> hasn't recovered by then, pciehp reports "device recovery failed" and
> the device is re-enumerated.
>
> Move PCIE_RESET_READY_POLL_MS definition from pci.c to pci.h so it can be
> used in dpc.c. Use PCIE_RESET_READY_POLL_MS (60 seconds) as the timeout
> so pciehp waits as long as pci_dev_wait() does, which is sufficient for
> all known devices.
>
> Tested with INNOGRIT NVMe SSD [1dbe:5668] with ACS Fatal error
> injection:
>
> Upstream kernel (7.3.0-master+, 4s timeout):
> [123.018691] nvme: not ready 1023ms after DPC; waiting
> [124.106690] nvme: not ready 2047ms after DPC; waiting
Was there a "not ready ... after DPC; giving up" message here?
pci_dev_wait() should log *something* about how it resolved this
situation.
> [125.642703] pciehp: Slot(64): Link Down
> [126.218696] AER: subordinate device reset failed
> [126.218700] AER: device recovery failed
> Device re-enumerated as nvme1
>
> With this patch (60s timeout):
> [74.894811] nvme: not ready 1023ms after DPC; waiting
> [75.982813] nvme: not ready 2047ms after DPC; waiting
> [78.094810] nvme: ready 4095ms after DPC
> [78.094816] nvme: restart after slot reset
> [78.111620] AER: device recovery successful
> Device works normally
>
> Fixes: a97396c6eb13 ("PCI: pciehp: Ignore Link Down/Up caused by DPC")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ziyou Wang (Lenovo) <ziyou.dev@foxmail.com>
> ---
30 minutes after v1 is too soon to post a v2. A couple days is a
reasonable interval.
v2 should include a note here (after the "---") about what changed
since v1 and ideally a lore link to the v1 posting.
prev parent reply other threads:[~2026-11-06 15:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20261106082612.1840817-1-ziyou.dev@foxmail.com>
2026-11-06 8:56 ` [PATCH v2] PCI/DPC: Increase recovery timeout to 60 seconds Ziyou Wang (Lenovo)
2026-11-06 9:05 ` sashiko-bot
2026-11-06 15:21 ` Bjorn Helgaas [this message]
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=20261106152143.GA1621130@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=stable@vger.kernel.org \
--cc=ziyou.dev@foxmail.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.