* [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602
@ 2023-07-14 13:13 Han Gao
2023-08-17 5:32 ` Felix Yan
0 siblings, 1 reply; 6+ messages in thread
From: Han Gao @ 2023-07-14 13:13 UTC (permalink / raw)
To: kbusch, axboe, hch, sagi; +Cc: linux-nvme, linux-kernel, Han Gao, David Xu
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 */
--
2.41.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602
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
0 siblings, 0 replies; 6+ messages in thread
From: Felix Yan @ 2023-08-17 5:32 UTC (permalink / raw)
To: Han Gao, kbusch, axboe, hch, sagi; +Cc: linux-nvme, linux-kernel, David Xu
[-- 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 --]
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602
2023-07-22 14:07 ` Josh Taylor
@ 2023-07-22 14:42 ` Sean Wang
0 siblings, 0 replies; 6+ messages in thread
From: Sean Wang @ 2023-07-22 14:42 UTC (permalink / raw)
To: Josh Taylor
Cc: axboe, hch, highenthalpyh, kbusch, linux-kernel, linux-nvme, sagi, xuwd1
Try latest Manjaro(install with ISO and update the system with around 2GB downloads). That worked for me to recognize my both MAP1602 SSDs: Aigo P7000z and Fanxiang S790.
Sent from my mobile device.
> 在 2023年7月22日，22:08，Josh Taylor <joshuataylorx@gmail.com> 写道：
>
> This is my first response to a Kernel patch, so I apologise for any formatting weirdness.
>
> I have a Lexar NM790 (4TB), which uses the MAP1602. It looks like this is going to be a fairly popular controller, as it seems a few are using it - as of July 2023 it looks like ~18 M.2 2280 are using it according to techpowerup (https://www.techpowerup.com/ssd-specs/?f&controllerMfgr=Maxiotech#MAP1602).
>
> I however cannot get this patch to work for me on 6.5-rc2 on ArchLinux, nor with 6.4.4.
>
> This is my dmesg when booting (Linux archiso 6.3.9-arch1-1):
>
>
> [ 6.634874] nvme nvme0: pci function 0000:01:00.0
> [ 6.640698] r8169 0000:27:00.0: enabling device (0000 -> 0003)
> [ 6.643601] nvme nvme0: Device not ready; aborting initialisation, CSTS=0x0
>
>
> When doing a suspend, then resuming, I can then re-initialise the device using the rescan steps in the previous email.
>
> I then get this in my dmesg (Linux archiso 6.3.9-arch1-1):
>
>
> [ 130.948667] pci 0000:01:00.0: Removing from iommu group 14
> [ 131.983938] pci 0000:01:00.0: [1d97:1602] type 00 class 0x010802
> [ 131.983963] pci 0000:01:00.0: reg 0x10: [mem 0xfcf00000-0xfcf03fff 64bit]
> [ 131.984212] pci 0000:01:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)
> [ 131.984346] pci 0000:01:00.0: Adding to iommu group 14
> [ 132.031556] pci 0000:01:00.0: BAR 0: assigned [mem 0xfcf00000-0xfcf03fff 64bit]
> [ 132.031662] nvme nvme0: pci function 0000:01:00.0
> [ 132.044095] nvme nvme0: allocated 40 MiB host memory buffer.
> [ 132.088892] nvme nvme0: 16/0/0 default/read/poll queues
>
>
> The "allocated 40 MiB host memory buffer" part is interesting, none of my other drives have this, as this is a DRAM-less drive.
>
> # nvme get-feature /dev/nvme0 -f 0x0c -H
> get-feature:0x0c (Autonomous Power State Transition), Current value:0x00000001
> Autonomous Power State Transition Enable (APSTE): Enabled
> Auto PST Entries .................
> Entry[ 0]
> .................
> Idle Time Prior to Transition (ITPT): 100 ms
> Idle Transition Power State (ITPS): 3
> .................
> Entry[ 1]
> .................
> Idle Time Prior to Transition (ITPT): 100 ms
> Idle Transition Power State (ITPS): 3
> .................
> Entry[ 2]
> .................
> Idle Time Prior to Transition (ITPT): 100 ms
> Idle Transition Power State (ITPS): 3
> .................
> Entry[ 3]
> .................
> Idle Time Prior to Transition (ITPT): 2000 ms
> Idle Transition Power State (ITPS): 4
> .................
> Entry[ 4]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[ 5]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[ 6]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[ 7]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[ 8]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[ 9]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[10]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[11]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[12]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[13]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[14]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[15]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[16]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[17]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[18]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[19]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[20]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[21]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[22]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[23]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[24]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[25]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[26]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[27]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[28]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[29]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[30]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
> Entry[31]
> .................
> Idle Time Prior to Transition (ITPT): 0 ms
> Idle Transition Power State (ITPS): 0
> .................
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602
2023-07-18 2:10 Sean Wang
@ 2023-07-22 14:07 ` Josh Taylor
2023-07-22 14:42 ` Sean Wang
0 siblings, 1 reply; 6+ messages in thread
From: Josh Taylor @ 2023-07-22 14:07 UTC (permalink / raw)
To: wangxiao
Cc: axboe, hch, highenthalpyh, kbusch, linux-kernel, linux-nvme, sagi, xuwd1
This is my first response to a Kernel patch, so I apologise for any formatting weirdness.
I have a Lexar NM790 (4TB), which uses the MAP1602. It looks like this is going to be a fairly popular controller, as it seems a few are using it - as of July 2023 it looks like ~18 M.2 2280 are using it according to techpowerup (https://www.techpowerup.com/ssd-specs/?f&controllerMfgr=Maxiotech#MAP1602).
I however cannot get this patch to work for me on 6.5-rc2 on ArchLinux, nor with 6.4.4.
This is my dmesg when booting (Linux archiso 6.3.9-arch1-1):
[ 6.634874] nvme nvme0: pci function 0000:01:00.0
[ 6.640698] r8169 0000:27:00.0: enabling device (0000 -> 0003)
[ 6.643601] nvme nvme0: Device not ready; aborting initialisation, CSTS=0x0
When doing a suspend, then resuming, I can then re-initialise the device using the rescan steps in the previous email.
I then get this in my dmesg (Linux archiso 6.3.9-arch1-1):
[ 130.948667] pci 0000:01:00.0: Removing from iommu group 14
[ 131.983938] pci 0000:01:00.0: [1d97:1602] type 00 class 0x010802
[ 131.983963] pci 0000:01:00.0: reg 0x10: [mem 0xfcf00000-0xfcf03fff 64bit]
[ 131.984212] pci 0000:01:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:00:01.1 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)
[ 131.984346] pci 0000:01:00.0: Adding to iommu group 14
[ 132.031556] pci 0000:01:00.0: BAR 0: assigned [mem 0xfcf00000-0xfcf03fff 64bit]
[ 132.031662] nvme nvme0: pci function 0000:01:00.0
[ 132.044095] nvme nvme0: allocated 40 MiB host memory buffer.
[ 132.088892] nvme nvme0: 16/0/0 default/read/poll queues
The "allocated 40 MiB host memory buffer" part is interesting, none of my other drives have this, as this is a DRAM-less drive.
# nvme get-feature /dev/nvme0 -f 0x0c -H
get-feature:0x0c (Autonomous Power State Transition), Current value:0x00000001
Autonomous Power State Transition Enable (APSTE): Enabled
Auto PST Entries .................
Entry[ 0]
.................
Idle Time Prior to Transition (ITPT): 100 ms
Idle Transition Power State (ITPS): 3
.................
Entry[ 1]
.................
Idle Time Prior to Transition (ITPT): 100 ms
Idle Transition Power State (ITPS): 3
.................
Entry[ 2]
.................
Idle Time Prior to Transition (ITPT): 100 ms
Idle Transition Power State (ITPS): 3
.................
Entry[ 3]
.................
Idle Time Prior to Transition (ITPT): 2000 ms
Idle Transition Power State (ITPS): 4
.................
Entry[ 4]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[ 5]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[ 6]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[ 7]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[ 8]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[ 9]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[10]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[11]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[12]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[13]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[14]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[15]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[16]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[17]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[18]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[19]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[20]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[21]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[22]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[23]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[24]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[25]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[26]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[27]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[28]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[29]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[30]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
Entry[31]
.................
Idle Time Prior to Transition (ITPT): 0 ms
Idle Transition Power State (ITPS): 0
.................
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602
@ 2023-07-18 2:10 Sean Wang
2023-07-22 14:07 ` Josh Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Sean Wang @ 2023-07-18 2:10 UTC (permalink / raw)
To: Keith Busch
Cc: highenthalpyh, axboe, hch, linux-kernel, linux-nvme, sagi, xuwd1
Could you please point out which patch in 6.5-rc2 for such devices? Thanks
Sent from my mobile device.
> 在 2023年7月17日，16:03，Keith Busch <kbusch@kernel.org> 写道：
>
> On Mon, Jul 17, 2023 at 07:41:26AM +0000, Sean Wang wrote:
>> My two SSDs are from different companies, but they all use MaxIO 1602 nvme controllers.
>>
>> After applying this patch, they could work.
>>
>> Otherwise, here is a workaround to make live cd to recognize these SSDs:
>>
>>
>> echo “1” > /sys/bus/pci/devices/0000:02:00.0/remove
>> sleep 1
>> echo “1” > /sys/bus/pci/rescan
>>
>> Where device id (02:00.0) could be found via
>>
>> lspci -nn -d ::0108
>
> We have a generic solution for such devices as of 6.5-rc2 so it should
> work now; however, it's still recommended to get devices with this
> behavior in the quirk list in order to ensure that the we get udev to
> generate deterministic symlinks. Since this controller is used by
> multiple vendors, though, it's unclear if this quirk applies to all
> variations.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] nvme-pci: add NVME_QUIRK_DELAY_BEFORE_CHK_RDY for MAXIO MAP1602
[not found] <MEAP282MB039120C4DEF97CED9B4CE841B33BA@MEAP282MB0391.AUSP282.PROD.OUTLOOK.COM>
@ 2023-07-17 8:03 ` Keith Busch
0 siblings, 0 replies; 6+ messages in thread
From: Keith Busch @ 2023-07-17 8:03 UTC (permalink / raw)
To: Sean Wang
Cc: highenthalpyh, axboe, hch, linux-kernel, linux-nvme, sagi, xuwd1
On Mon, Jul 17, 2023 at 07:41:26AM +0000, Sean Wang wrote:
> My two SSDs are from different companies, but they all use MaxIO 1602 nvme controllers.
>
> After applying this patch, they could work.
>
> Otherwise, here is a workaround to make live cd to recognize these SSDs:
>
>
> echo “1” > /sys/bus/pci/devices/0000:02:00.0/remove
> sleep 1
> echo “1” > /sys/bus/pci/rescan
>
> Where device id (02:00.0) could be found via
>
> lspci -nn -d ::0108
We have a generic solution for such devices as of 6.5-rc2 so it should
work now; however, it's still recommended to get devices with this
behavior in the quirk list in order to ensure that the we get udev to
generate deterministic symlinks. Since this controller is used by
multiple vendors, though, it's unclear if this quirk applies to all
variations.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-08-17 5:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
[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
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).