This commit adds NVME_QUIRK_BOGUS_NID for device [1cc4:6a14], the
Shenzhen Unionmemory Information System Ltd. RPEYJ1T24MKN2QWY PCIe
4.0 NVMe SSD 1024GB (DRAM-less), which can be found on many Lenovo
notebooks. This SSD produces all-zero nguid.
Other SSDs manufatured by Shenzhen Unionmemory Information System
Ltd are likely to face similar issues, but I currently have no
device to test.
Signed-off-by: Holger Huo <[email protected]>
---
drivers/nvme/host/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 8e0bb9692..b478b1736 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -3482,6 +3482,8 @@ static const struct pci_device_id nvme_id_table[] = {
.driver_data = NVME_QUIRK_BOGUS_NID, },
{ PCI_DEVICE(0x10ec, 0x5765), /* TEAMGROUP MP33 2TB SSD */
.driver_data = NVME_QUIRK_BOGUS_NID, },
+ { PCI_DEVICE(0x1cc4, 0x6a14), /* UMIS PCIe 4.0 NVMe SSD 1024GB (DRAM-less) */
+ .driver_data = NVME_QUIRK_BOGUS_NID, },
{ PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0061),
.driver_data = NVME_QUIRK_DMA_ADDRESS_BITS_48, },
{ PCI_DEVICE(PCI_VENDOR_ID_AMAZON, 0x0065),
--
2.44.0
On Wed, Apr 10, 2024 at 03:28:50AM +0800, Holger Huo wrote:
> This commit adds NVME_QUIRK_BOGUS_NID for device [1cc4:6a14], the
> Shenzhen Unionmemory Information System Ltd. RPEYJ1T24MKN2QWY PCIe
> 4.0 NVMe SSD 1024GB (DRAM-less), which can be found on many Lenovo
> notebooks. This SSD produces all-zero nguid.
>
> Other SSDs manufatured by Shenzhen Unionmemory Information System
> Ltd are likely to face similar issues, but I currently have no
> device to test.
Are you using the most recent stable kernel and still need this patch?
These quirks shouldn't be necessary anymore unless it's advertising
multipath capabilities, and it doesn't sound like this one should be
doing that.
On Wednesday, April 10, 2024 4:14:42 AM +08 Keith Busch wrote:
> On Wed, Apr 10, 2024 at 03:28:50AM +0800, Holger Huo wrote:
> > This commit adds NVME_QUIRK_BOGUS_NID for device [1cc4:6a14], the
> > Shenzhen Unionmemory Information System Ltd. RPEYJ1T24MKN2QWY PCIe
> > 4.0 NVMe SSD 1024GB (DRAM-less), which can be found on many Lenovo
> > notebooks. This SSD produces all-zero nguid.
> >
> > Other SSDs manufatured by Shenzhen Unionmemory Information System
> > Ltd are likely to face similar issues, but I currently have no
> > device to test.
>
> Are you using the most recent stable kernel and still need this patch?
> These quirks shouldn't be necessary anymore unless it's advertising
> multipath capabilities, and it doesn't sound like this one should be
> doing that.
Yes. My current Linux kernel version is 6.8.4 by arch. After further
investigation I found these quirks truly had no effects.
But my nvme drive still freezes with Device not ready; aborting reset,
CSTS=0x1 failures and AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001 ...]
waking from s0 (s2idle) sleep. Are there any other quirks or what that I
should try
On Wed, Apr 10, 2024 at 10:05:46AM +0800, Holger Huo wrote:
> On Wednesday, April 10, 2024 4:14:42 AM +08 Keith Busch wrote:
> > On Wed, Apr 10, 2024 at 03:28:50AM +0800, Holger Huo wrote:
> > > This commit adds NVME_QUIRK_BOGUS_NID for device [1cc4:6a14], the
> > > Shenzhen Unionmemory Information System Ltd. RPEYJ1T24MKN2QWY PCIe
> > > 4.0 NVMe SSD 1024GB (DRAM-less), which can be found on many Lenovo
> > > notebooks. This SSD produces all-zero nguid.
> > >
> > > Other SSDs manufatured by Shenzhen Unionmemory Information System
> > > Ltd are likely to face similar issues, but I currently have no
> > > device to test.
> >
> > Are you using the most recent stable kernel and still need this patch?
> > These quirks shouldn't be necessary anymore unless it's advertising
> > multipath capabilities, and it doesn't sound like this one should be
> > doing that.
>
> Yes. My current Linux kernel version is 6.8.4 by arch. After further
> investigation I found these quirks truly had no effects.
> But my nvme drive still freezes with Device not ready; aborting reset,
> CSTS=0x1 failures and AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001 ...]
> waking from s0 (s2idle) sleep. Are there any other quirks or what that I
> should try
I've seen the IO_PAGE_FAULT error reported before, but all I've heard is
that it means the device attempts to access a memory address that it is
not allowed to. I don't know why that would happen, though. I've never
first hand experience with this condition, I'm just as confused.
On Wednesday, April 10, 2024 11:08:58 AM +08 Keith Busch wrote:
> On Wed, Apr 10, 2024 at 10:05:46AM +0800, Holger Huo wrote:
> > On Wednesday, April 10, 2024 4:14:42 AM +08 Keith Busch wrote:
> > > On Wed, Apr 10, 2024 at 03:28:50AM +0800, Holger Huo wrote:
> > > > This commit adds NVME_QUIRK_BOGUS_NID for device [1cc4:6a14], the
> > > > Shenzhen Unionmemory Information System Ltd. RPEYJ1T24MKN2QWY PCIe
> > > > 4.0 NVMe SSD 1024GB (DRAM-less), which can be found on many Lenovo
> > > > notebooks. This SSD produces all-zero nguid.
> > > >
> > > > Other SSDs manufatured by Shenzhen Unionmemory Information System
> > > > Ltd are likely to face similar issues, but I currently have no
> > > > device to test.
> > >
> > > Are you using the most recent stable kernel and still need this patch?
> > > These quirks shouldn't be necessary anymore unless it's advertising
> > > multipath capabilities, and it doesn't sound like this one should be
> > > doing that.
> >
> > Yes. My current Linux kernel version is 6.8.4 by arch. After further
> > investigation I found these quirks truly had no effects.
> > But my nvme drive still freezes with Device not ready; aborting reset,
> > CSTS=0x1 failures and AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001
> > ...] waking from s0 (s2idle) sleep. Are there any other quirks or what
> > that I should try
>
> I've seen the IO_PAGE_FAULT error reported before, but all I've heard is
> that it means the device attempts to access a memory address that it is
> not allowed to. I don't know why that would happen, though. I've never
> first hand experience with this condition, I'm just as confused.
Thanks for your help! I found this to be IOMMU related and I have to set
AMD_IOMMU=off to have it working. This is not nvme driver related. Sorry for
making this patch.