Received-SPF: pass (google.com: domain of linux-kernel+bounces-137859-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Tue, 9 Apr 2024 21:08:58 -0600
From: Keith Busch <kbusch@kernel.org>
To: Holger Huo <holgerhuo@outlook.com>
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
	Holger Huo <i@holger.one>
Subject: Re: [PATCH] drivers/nvme: Add quirks for device 1cc4:6a14
Message-ID: <ZhYCyuP6vTJq-TZq@kbusch-mbp.dhcp.thefacebook.com>
References: <ME3P282MB24818FA28E7C73BC01302882B5072@ME3P282MB2481.AUSP282.PROD.OUTLOOK.COM>
 <ZhWhshq7hpPd9XrI@kbusch-mbp.dhcp.thefacebook.com>
 <ME3P282MB2481C1DC0506D154FA3AA3D2B5062@ME3P282MB2481.AUSP282.PROD.OUTLOOK.COM>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ME3P282MB2481C1DC0506D154FA3AA3D2B5062@ME3P282MB2481.AUSP282.PROD.OUTLOOK.COM>

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.