From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
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 16:10:54 +0200 [thread overview]
Message-ID: <20190523141054.GA19635@lst.de> (raw)
In-Reply-To: <20190523132304.GB14049@localhost.localdomain>
On Thu, May 23, 2019 at 07:23:04AM -0600, Keith Busch wrote:
> > 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?
What would be the point of the AEN if it wasn't sent at exactly
the point when the controller stops acceppting command?
The wording is of course NVMe-like, but "The controller is starting a.."
pretty clear implies this is sent at the beginning of the paused
state, not the end.
next prev parent reply other threads:[~2019-05-23 14:11 UTC|newest]
Thread overview: 15+ 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 ` [PATCH 1/2] blk-mq: provide way to reset rq deadline Keith Busch
2019-05-22 17:48 ` [PATCH 2/2] nvme: reset request timeouts during fw activation Keith Busch
2019-05-23 10:19 ` Ming Lei
2019-05-23 13:34 ` Keith Busch
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:28 ` Keith Busch
2019-05-23 10:04 ` Bart Van Assche
2019-05-23 3:29 ` Ming Lei
2019-05-23 3:48 ` Keith Busch
2019-05-23 10:13 ` Christoph Hellwig
2019-05-23 13:23 ` Keith Busch
2019-05-23 14:10 ` Christoph Hellwig [this message]
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=20190523141054.GA19635@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=kbusch@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).