Bug 215081 - nvme: Device not ready; aborting reset, CSTS=0x1 - Removing after probe failure status: -19
Summary: nvme: Device not ready; aborting reset, CSTS=0x1 - Removing after probe failu...
Status: CLOSED CODE_FIX
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: NVMe (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: IO/NVME Virtual Default Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-20 10:52 UTC by Peter
Modified: 2021-11-22 15:39 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.15.3 (5.14.20)
Subsystem:
Regression: No
Bisected commit-id:


Attachments
config and dmesg (66.23 KB, application/x-compressed-tar)
2021-11-20 10:52 UTC, Peter
Details

Description Peter 2021-11-20 10:52:52 UTC
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
Comment 1 Peter 2021-11-22 10:04:28 UTC
Fixed with 5.15.4.
Comment 2 Keith Busch 2021-11-22 15:39:30 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.