Date: Fri, 1 Oct 2021 17:10:23 GMT From: Warner Losh <imp@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: git: e5e26e4a24a1 - main - nvme: Remove pause while resetting Message-ID: <202110011710.191HANo4026521@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by imp: URL: https://cgit.FreeBSD.org/src/commit/?id=e5e26e4a24a1142e02a9b477877e13ed0c194f36 commit e5e26e4a24a1142e02a9b477877e13ed0c194f36 Author: Warner Losh <imp@FreeBSD.org> AuthorDate: 2021-10-01 17:09:05 +0000 Commit: Warner Losh <imp@FreeBSD.org> CommitDate: 2021-10-01 17:09:05 +0000 nvme: Remove pause while resetting After some study of the code and the standard, I think we can just drop the pause(), unconditionally. If we're not initialized, then there's nothing to wait for from a software perspective. If we are initialized, then there might be outstanding I/O. If so, then the qpair 'recovery state' will transition to WAITING in nvme_ctrlr_disable_qpairs, which will ignore any interrupts for items that complete before we complete the reset by setting cc.en=0. If we go on to fail the controller, we'll cancel the outstanding I/O transactions. If we reset the controller, the hardware throws away pending transactions and we retry all the pending I/O transactions. Any transactions that happend to complete before cc.en=0 will have the same effect in the end (doing the same transaction twice is just inefficient, it won't affect the state of the device any differently than having done it once). The standard imposes no wait times here, so it isn't needed from that perspective. Unanswered Question: Do we may need to disable interrupts while we disable in legacy mode since those are level-sensitive. Sponsored by: Netflix Reviewed by: mav Differential Revision: https://reviews.freebsd.org/D32248 --- sys/dev/nvme/nvme_ctrlr.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/sys/dev/nvme/nvme_ctrlr.c b/sys/dev/nvme/nvme_ctrlr.c index eb95fa33b90b..d0be0da39902 100644 --- a/sys/dev/nvme/nvme_ctrlr.c +++ b/sys/dev/nvme/nvme_ctrlr.c @@ -410,13 +410,13 @@ nvme_ctrlr_hw_reset(struct nvme_controller *ctrlr) int err; TSENTER(); - nvme_ctrlr_disable_qpairs(ctrlr); - pause("nvmehwreset", hz / 10); + nvme_ctrlr_disable_qpairs(ctrlr); err = nvme_ctrlr_disable(ctrlr); if (err != 0) return err; + err = nvme_ctrlr_enable(ctrlr); TSEXIT(); return (err); @@ -1653,13 +1653,10 @@ nvme_ctrlr_suspend(struct nvme_controller *ctrlr) * flushes any metadata the drive may have stored so it can survive * having its power removed and prevents the unsafe shutdown count from * incriminating. Once we delete the qpairs, we have to disable them - * before shutting down. The delay is out of paranoia in - * nvme_ctrlr_hw_reset, and is repeated here (though we should have no - * pending I/O that the delay copes with). + * before shutting down. */ nvme_ctrlr_delete_qpairs(ctrlr); nvme_ctrlr_disable_qpairs(ctrlr); - pause("nvmesusp", hz / 10); nvme_ctrlr_shutdown(ctrlr); return (0);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202110011710.191HANo4026521>