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: <aR-CUUzWzQKIAfqx@kbusch-mbp>
Date: Thu, 20 Nov 2025 14:04:17 -0700
From: Keith Busch <kbusch@...nel.org>
To: Thomas ten Cate <ttencate@...il.com>
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

On Thu, Nov 20, 2025 at 02:52:22PM +0100, Thomas ten Cate wrote:
> On Tue, Nov 18, 2025 at 9:49 PM Keith Busch <kbusch@...nel.org> wrote:
> >
> > The "report a bug" message was originally pointed at hardware vendors
> > rather than kernel. Something is wrong with the SSD, the PCIe slot, or
> > both if the power features cause the endpoint to drop off the bus. The
> > only recourse we have in the nvme driver is a quirk to disable APST for
> > the device. The driver doesn't control the PCIe ASPM settings though, so
> > that would have to be a different quirk if it's really necessary. Do you
> > need all three of those parameters, or is disabling the nvme driver's
> > apst sufficient on its own? These parameters do have a negative impact
> > on your machine's power consumption, so you'd usually want to hone in if
> > it's just the deepest power state or if every power saving feature
> > really needs to be disabled.
> 
> Thanks for your reply!
> 
> Just `nvme_core.default_ps_max_latency_us=0` appears to be sufficient,
> so presumably it's the drive, not the bus. I wouldn't even know where
> to begin reporting a bug to the manufacturer.

I assume vendor 0x1c5c for SK Hynix, but we also need the device id to
make a quirk. You can get that info from sysfs, for example if your
device is enumerated as "nvme0":

  # cat /sys/class/nvme/nvme0/device/device

There's two quirks we can try: NVME_QUIRK_NO_DEEPEST_PS first, then
NVME_QUIRK_NO_APST if the first one wasn't successful.