From: Keith Busch <kbusch@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <keith.busch@gmail.com>,
Ming Lei <ming.lei@redhat.com>,
"Busch, Keith" <keith.busch@intel.com>,
Jens Axboe <axboe@kernel.dk>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
linux-nvme <linux-nvme@lists.infradead.org>
Subject: Re: [PATCH 0/2] Reset timeout for paused hardware
Date: Thu, 23 May 2019 07:23:04 -0600 [thread overview]
Message-ID: <20190523132304.GB14049@localhost.localdomain> (raw)
In-Reply-To: <20190523101311.GB15492@lst.de>
On Thu, May 23, 2019 at 03:13:11AM -0700, Christoph Hellwig wrote:
> On Wed, May 22, 2019 at 09:48:10PM -0600, Keith Busch wrote:
> > Yeah, that's a good question. A FW update may have been initiated out
> > of band or from another host entirely. The driver can't count on
> > preparing for hardware pausing command processing before it's
> > happened, but we'll always find out asynchronously after it's too late
> > to freeze.
>
> I don't think that is the case at least for spec compliant devices.
>
> From NVMe 1.3:
>
> Figure 49: Asynchronous Event Information - Notice
>
> 1h Firmware Activation Starting: The controller is starting
> a firmware activation process during which command
> processing is paused. Host software may use CSTS.PP to
> determine when command processing has resumed. To clear
> this event, host software reads the Firmware Slot
> Information log page.
>
> So we are supposed to get an AEN before the device stops processing
> commands.
Hm, I read the same section, but conclude differently (and at least some
vendors did too). A spec compliant controller activating new firmware
without reset would stop processing commands and set CSTS.PP first,
then send the AEN. When the host is aware to poll Processing Paused,
the controller hasn't been processing new commands for some time.
Could you give some more detail on your interpretation?
WARNING: multiple messages have this Message-ID (diff)
From: kbusch@kernel.org (Keith Busch)
Subject: [PATCH 0/2] Reset timeout for paused hardware
Date: Thu, 23 May 2019 07:23:04 -0600 [thread overview]
Message-ID: <20190523132304.GB14049@localhost.localdomain> (raw)
In-Reply-To: <20190523101311.GB15492@lst.de>
On Thu, May 23, 2019@03:13:11AM -0700, Christoph Hellwig wrote:
> On Wed, May 22, 2019@09:48:10PM -0600, Keith Busch wrote:
> > Yeah, that's a good question. A FW update may have been initiated out
> > of band or from another host entirely. The driver can't count on
> > preparing for hardware pausing command processing before it's
> > happened, but we'll always find out asynchronously after it's too late
> > to freeze.
>
> I don't think that is the case at least for spec compliant devices.
>
> From NVMe 1.3:
>
> Figure 49: Asynchronous Event Information - Notice
>
> 1h Firmware Activation Starting: The controller is starting
> a firmware activation process during which command
> processing is paused. Host software may use CSTS.PP to
> determine when command processing has resumed. To clear
> this event, host software reads the Firmware Slot
> Information log page.
>
> So we are supposed to get an AEN before the device stops processing
> commands.
Hm, I read the same section, but conclude differently (and at least some
vendors did too). A spec compliant controller activating new firmware
without reset would stop processing commands and set CSTS.PP first,
then send the AEN. When the host is aware to poll Processing Paused,
the controller hasn't been processing new commands for some time.
Could you give some more detail on your interpretation?
next prev parent reply other threads:[~2019-05-23 13:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-22 17:48 [PATCH 0/2] Reset timeout for paused hardware Keith Busch
2019-05-22 17:48 ` Keith Busch
2019-05-22 17:48 ` [PATCH 1/2] blk-mq: provide way to reset rq deadline Keith Busch
2019-05-22 17:48 ` Keith Busch
2019-05-22 17:48 ` [PATCH 2/2] nvme: reset request timeouts during fw activation Keith Busch
2019-05-22 17:48 ` Keith Busch
2019-05-23 10:19 ` Ming Lei
2019-05-23 10:19 ` Ming Lei
2019-05-23 13:34 ` Keith Busch
2019-05-23 13:34 ` Keith Busch
2019-05-23 14:07 ` Christoph Hellwig
2019-05-23 14:07 ` Christoph Hellwig
2019-05-22 20:20 ` [PATCH 0/2] Reset timeout for paused hardware Bart Van Assche
2019-05-22 20:20 ` Bart Van Assche
2019-05-22 20:28 ` Keith Busch
2019-05-22 20:28 ` Keith Busch
2019-05-23 10:04 ` Bart Van Assche
2019-05-23 10:04 ` Bart Van Assche
2019-05-23 3:29 ` Ming Lei
2019-05-23 3:29 ` Ming Lei
2019-05-23 3:48 ` Keith Busch
2019-05-23 3:48 ` Keith Busch
2019-05-23 10:13 ` Christoph Hellwig
2019-05-23 10:13 ` Christoph Hellwig
2019-05-23 13:23 ` Keith Busch [this message]
2019-05-23 13:23 ` Keith Busch
2019-05-23 14:10 ` Christoph Hellwig
2019-05-23 14:10 ` Christoph Hellwig
2019-05-23 14:19 ` Keith Busch
2019-05-23 14:19 ` 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=20190523132304.GB14049@localhost.localdomain \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=keith.busch@gmail.com \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=ming.lei@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 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.