linux-kernel - Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7cd693dd-a6d7-4aab-aef0-76a8366ceee6@archlinux.org>
Date:   Thu, 17 Aug 2023 08:32:52 +0300
From:   Felix Yan <felixonmars@...hlinux.org>
To:     Han Gao <highenthalpyh@...il.com>, kbusch@...nel.org,
        axboe@...nel.dk, hch@....de, sagi@...mberg.me
Cc:     linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org,
        David Xu <xuwd1@...mail.com>
Subject: Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO
 MAP1602

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@...il.com>
> Signed-off-by: David Xu <xuwd1@...mail.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


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)