Bug 215081
Summary: | nvme: Device not ready; aborting reset, CSTS=0x1 - Removing after probe failure status: -19 | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Peter (chissel) |
Component: | NVMe | Assignee: | IO/NVME Virtual Default Assignee (io_nvme) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | kbusch |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 5.15.3 (5.14.20) | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | config and dmesg |
Fixed with 5.15.4. Strange. There are zero nvme driver commits between 5.15.3 and 5.15.4. I suspect that whatever made it work may be coincidental. In my experience, a stuck CSTS.RDY bit has always been the fault of controller firmware. |
Created attachment 299649 [details] config and dmesg Have tested this first with gentoo-sources 5.15.3 and 5.14.20. After that with upstream kernel 5.15.3 (with make oldconfig). Error is the same. All previous versions were working ok even when rebuilded now. Trying to apply commandline parameter nvme_core.default_ps_max_latency_us=0 or nvme_core.default_ps_max_latency_us=5500 ===> same result. Configuration: efi-stub kernel with embedded intram which boots until cryptsetup is trying to access the nvme (not in /dev ofc). Files: .config dmesg-5.15.3-upstream.txt dmesg-5.15.3-upstream-nvme_core.default_ps_max_latency_us.txt