From: Christoph Hellwig <hch@lst.de>
To: "Michael Kelley (LINUX)" <mikelley@microsoft.com>
Cc: Christoph Hellwig <hch@lst.de>,
"kbusch@kernel.org" <kbusch@kernel.org>,
"axboe@fb.com" <axboe@fb.com>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Caroline Subramoney <Caroline.Subramoney@microsoft.com>,
Richard Wurdack <riwurd@microsoft.com>,
Nathan Obr <Nathan.Obr@microsoft.com>
Subject: Re: [PATCH 2/2] nvme-pci: handle persistent internal error AER from NVMe controller
Date: Wed, 1 Jun 2022 19:08:47 +0200 [thread overview]
Message-ID: <20220601170847.GA27165@lst.de> (raw)
In-Reply-To: <PH0PR21MB302599C693F0A48F3777008ED7DF9@PH0PR21MB3025.namprd21.prod.outlook.com>
On Wed, Jun 01, 2022 at 03:56:59PM +0000, Michael Kelley (LINUX) wrote:
> If there is a persistent error that does a controller reset, it looks
> like we should *not* queue async_event_work at the end of
> nvme_complete_async_event(). The controller reset will
> submit an AER on the admin queue, and so presumably
> we don't want nvme_async_event_work() to also try to submit
> another AER, which may or may not succeed depending on the
> timing of when the controller state shows LIVE again.
> Agreed?
Yes, that makes sense. I guess we can just check the return value
from nvme_reset_ctrl and propagate this to nvme_async_event_work
and skip the rearming for that case.
prev parent reply other threads:[~2022-06-01 17:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-01 4:12 [PATCH 1/2] nvme-pci: Move two functions to avoid forward reference Michael Kelley
2022-06-01 4:12 ` [PATCH 2/2] nvme-pci: handle persistent internal error AER from NVMe controller Michael Kelley
2022-06-01 7:35 ` Christoph Hellwig
2022-06-01 15:56 ` Michael Kelley (LINUX)
2022-06-01 17:08 ` Christoph Hellwig [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=20220601170847.GA27165@lst.de \
--to=hch@lst.de \
--cc=Caroline.Subramoney@microsoft.com \
--cc=Nathan.Obr@microsoft.com \
--cc=axboe@fb.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mikelley@microsoft.com \
--cc=riwurd@microsoft.com \
--cc=sagi@grimberg.me \
/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.