From: Christoph Hellwig <hch@lst.de>
To: Greg Joyce <gjoyce@linux.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org, kbusch@kernel.org, axboe@fb.com,
sagi@grimberg.me, hare@suse.de, dwagner@suse.de,
msuchanek@suse.de, jonathan.derrick@linux.dev,
okozina@redhat.com, nilay@linux.ibm.com
Subject: Re: [PATCH 1/1] nvme: retry security commands if media not ready
Date: Thu, 3 Oct 2024 14:43:45 +0200 [thread overview]
Message-ID: <20241003124345.GA16754@lst.de> (raw)
In-Reply-To: <dbfd87e4900bea3a28ac46f5abcfb39ef2c13fc1.camel@linux.ibm.com>
On Wed, Oct 02, 2024 at 11:51:56AM -0500, Greg Joyce wrote:
> If we cache the timeout value(s) in nvme_ctrl then it may be possible
> to just eliminate nvme_get_timeout() entirely. Is this the approach
> that you were thinking?
Yes.
> I'm a little confused about what you're saying about the timeout.
> nvme_enable_ctrl() does determine the correct timeout value and passes
> it to nvme_wait_ready() but NVME_CSTS_RDY is set well before the media
> is ready (if CC.CRIME is set). Unfortunately there doesn't seem to be
> any controller status that indicates when the media is ready. I thought
> about having nvme_wait_ready() wait the whole timeout if CC.CRIME is
> set, but I think that is contrary to intent of CC.CRIME. And on the SSD
> that I'm looking at the timeout is 15 seconds which would be a pretty
> big hit to boot time.
What I mean is to simply set a timer for the controller ready timeout,
fire it when we set CC.EN and then the time sets a new media ready
flag in ctrl->flags. Then only retry when this flag is not set.
next prev parent reply other threads:[~2024-10-03 12:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 16:48 [PATCH 0/1] nvme: add retry for media not ready error gjoyce
2024-09-30 16:48 ` [PATCH 1/1] nvme: retry security commands if media not ready gjoyce
2024-10-02 8:16 ` Christoph Hellwig
2024-10-02 16:51 ` Greg Joyce
2024-10-03 12:43 ` Christoph Hellwig [this message]
2024-10-03 13:30 ` Greg Joyce
2024-10-03 14:41 ` Christoph Hellwig
2024-10-03 23:35 ` Greg Joyce
2024-10-04 5:41 ` Christoph Hellwig
2024-10-04 7:22 ` Nilay Shroff
2024-10-04 12:24 ` Christoph Hellwig
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=20241003124345.GA16754@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=dwagner@suse.de \
--cc=gjoyce@linux.ibm.com \
--cc=hare@suse.de \
--cc=jonathan.derrick@linux.dev \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=msuchanek@suse.de \
--cc=nilay@linux.ibm.com \
--cc=okozina@redhat.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.