Bug 215081

Summary: nvme: Device not ready; aborting reset, CSTS=0x1 - Removing after probe failure status: -19
Product: IO/Storage Reporter: Peter (chissel)
Component: NVMeAssignee: 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

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.