linux-kernel - Re: "controller is down; will reset" on SK Hynix NVMe drive in Lenovo IdeaPad Pro 5

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: <CACbz5yEJ_Fz8gtnCYsjvM09-UxosYOYOzbVODHe+HrEcS2oPPg@mail.gmail.com>
Date: Mon, 15 Dec 2025 13:15:54 +0100
From: Thomas ten Cate <ttencate@...il.com>
To: Keith Busch <kbusch@...nel.org>
Cc: Jens Axboe <axboe@...com>, Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>, 
	linux-nvme@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: "controller is down; will reset" on SK Hynix NVMe drive in Lenovo
 IdeaPad Pro 5

Sorry it took a while to get back to this.

Interestingly, the device ID is already in the table under the name
"BC901", with NVME_QUIRK_DISABLE_WRITE_ZEROES. From
https://product.skhynix.com/products/ssd/cssd/pc801_bc901.go I gather
that HFS001TEJ4X112N is *probably* an incarnation of the BC901 series,
although that exact model name is not listed there. The BC901 series
is supposed to be extra low-power... not waking up from sleep is
certainly a great way to accomplish that ;-)

I've attached a patch that works for me. But, like you said, this does
affect power usage, so I'm not sure it should be applied at all... at
least not until it's confirmed that I'm not the only one with this
problem. I'll leave that decision up to you.

On Mon, Nov 24, 2025 at 8:52 PM Keith Busch <kbusch@...nel.org> wrote:
>
> On Fri, Nov 21, 2025 at 02:06:23PM +0100, Thomas ten Cate wrote:
> > On Thu, Nov 20, 2025 at 10:04 PM Keith Busch <kbusch@...nel.org> wrote:
> >
> > I tried adding the following to linux/drivers/nvme/host/core.c, in the
> > core_quirks[] array. It takes a model name, not a device id, which I
> > took from /sys/class/nvme/nvme0/model.
> >
> > {
> >   .vid = 0x1c5c,
> >   .mn = "SKHynix_HFS001TEJ4X112N",
> >   .quirks = NVME_QUIRK_NO_APST,
> > }
> >
> > With NVME_QUIRK_NO_DEEPEST_PS, it still hung almost immediately. With
> > NVME_QUIRK_NO_APST, it appears to be stable.
> >
> > Would you like me to send a patch?
>
> Sure, but I think it'd be more universal to apply the quirk to the
> nvme-pci driver's pci device table than to make it based on the model.
> It's common for a model name to be different for various capacities, but
> I suspect the power behavior is more generic than that, which should be
> common with the device ID.

Download attachment "skhynix_hfs001tej4x112n.patch" of type "application/x-patch" (679 bytes)