From: Felix Yan <felixonmars@archlinux.org>
To: Han Gao <highenthalpyh@gmail.com>,
kbusch@kernel.org, axboe@kernel.dk, hch@lst.de, sagi@grimberg.me
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
David Xu <xuwd1@hotmail.com>
Subject: Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602
Date: Thu, 17 Aug 2023 08:32:52 +0300 [thread overview]
Message-ID: <7cd693dd-a6d7-4aab-aef0-76a8366ceee6@archlinux.org> (raw)
In-Reply-To: <20230714131333.5858-1-highenthalpyh@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3697 bytes --]
On 7/14/23 16:13, Han Gao wrote:
> 4TB SSD with MAXIO MAP1602 controller is cannot by initialised
> in nvme_enable_ctrl with a high probability, which causeds the system
> to be unable to use SSD, and SSD device only be shown in lspci.
>
> dmesg output of problem
>
> ----------
> nvme nvme1: Device not ready; aborting initialisation, CSTS=0x0
> ----------
>
> Problem and fix are verified with my MAP1602 controller SSD device.
>
> Signed-off-by: Han Gao <highenthalpyh@gmail.com>
> Signed-off-by: David Xu <xuwd1@hotmail.com>
> ---
> drivers/nvme/host/pci.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 492f319ebdf3..f75c27730bde 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -3425,7 +3425,8 @@ static const struct pci_device_id nvme_id_table[] = {
> { PCI_DEVICE(0x1e4B, 0x1202), /* MAXIO MAP1202 */
> .driver_data = NVME_QUIRK_BOGUS_NID, },
> { PCI_DEVICE(0x1e4B, 0x1602), /* MAXIO MAP1602 */
> - .driver_data = NVME_QUIRK_BOGUS_NID, },
> + .driver_data = NVME_QUIRK_BOGUS_NID |
> + NVME_QUIRK_DELAY_BEFORE_CHK_RDY, },
> { PCI_DEVICE(0x1cc1, 0x5350), /* ADATA XPG GAMMIX S50 */
> .driver_data = NVME_QUIRK_BOGUS_NID, },
> { PCI_DEVICE(0x1dbe, 0x5236), /* ADATA XPG GAMMIX S70 */
Unfortunately this doesn't fix it for me. As someone pointed out in the
forums [1], the quirk NVME_QUIRK_DELAY_BEFORE_CHK_RDY only takes effect
in nvme_disable_ctrl(), but we are hitting the timeout issue in
nvme_enable_ctrl() instead.
I have tried 6.5-rc5 with or without this patch but got mixed results
due to even more severe disk-writing related issues (deadlock in writing
to any disk).
With the following patch taken from the forums, the SSDs work flawlessly
on 6.4.X kernels:
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 3ec38e2b9173..ab2583cb42aa 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2408,6 +2408,7 @@ int nvme_enable_ctrl(struct nvme_ctrl *ctrl)
} else {
timeout = NVME_CAP_TIMEOUT(ctrl->cap);
}
+ dev_info(ctrl->device, "[PATCH] nvme core got timeout
%u\n",timeout);
ctrl->ctrl_config |= (NVME_CTRL_PAGE_SHIFT - 12) <<
NVME_CC_MPS_SHIFT;
ctrl->ctrl_config |= NVME_CC_AMS_RR | NVME_CC_SHN_NONE;
@@ -2425,8 +2426,9 @@ int nvme_enable_ctrl(struct nvme_ctrl *ctrl)
ret = ctrl->ops->reg_write32(ctrl, NVME_REG_CC, ctrl->ctrl_config);
if (ret)
return ret;
+ dev_info(ctrl->device, "[PATCH] nvme_wait_ready now wait for %u,
previously %u\n",(timeout + 1) * 2, (timeout + 1)/2);
return nvme_wait_ready(ctrl, NVME_CSTS_RDY, NVME_CSTS_RDY,
- (timeout + 1) / 2, "initialisation");
+ (timeout + 1) * 2, "initialisation");
}
EXPORT_SYMBOL_GPL(nvme_enable_ctrl);
Debug outputs in the dmesg:
[ 1.030057] nvme nvme1: [PATCH] nvme core got timeout 0
[ 1.030062] nvme nvme1: [PATCH] nvme_wait_ready now wait for 2,
previously 0
[ 1.031356] nvme nvme0: [PATCH] nvme core got timeout 0
[ 1.031368] nvme nvme0: [PATCH] nvme_wait_ready now wait for 2,
previously 0
6.1 LTS kernels don't have this problem because the timeout isn't 0 here.
Would it be a good idea to apply NVME_QUIRK_DELAY_BEFORE_CHK_RDY to
nvme_enable_ctrl too? Or shall we add another quirk just for this?
[1]
https://www.chiphell.com/forum.php?mod=viewthread&tid=2524660&extra=&page=5&mobile=no
(in Chinese)
--
Regards,
Felix Yan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2023-08-17 5:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-14 13:13 [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602 Han Gao
2023-08-17 5:32 ` Felix Yan [this message]
[not found] <MEAP282MB039120C4DEF97CED9B4CE841B33BA@MEAP282MB0391.AUSP282.PROD.OUTLOOK.COM>
2023-07-17 8:03 ` Keith Busch
2023-07-18 2:10 Sean Wang
2023-07-22 14:07 ` Josh Taylor
2023-07-22 14:42 ` Sean Wang
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=7cd693dd-a6d7-4aab-aef0-76a8366ceee6@archlinux.org \
--to=felixonmars@archlinux.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=highenthalpyh@gmail.com \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=xuwd1@hotmail.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).