NVMe CLI Invalid PRP Entry Status Failures
Avinash M N
Avinash.M.N at sandisk.com
Fri May 23 21:22:11 PDT 2025
The below function is causing the EINVAL to be returned to the userspace.
int blk_rq_append_bio(struct request *rq, struct bio *bio)
{
const struct queue_limits *lim = &rq->q->limits;
unsigned int max_bytes = lim->max_hw_sectors << SECTOR_SHIFT;
unsigned int nr_segs = 0;
int ret;
/* check that the data layout matches the hardware restrictions */
ret = bio_split_rw_at(bio, lim, &nr_segs, max_bytes);
if (ret) {
/* if we would have to split the bio, copy instead */
if (ret > 0) {
ret = -EREMOTEIO;
}
return ret;
}
There is no issue if nvme-cli sends a transfer length of up to 128K. Anything more than 128K is failed as ENINVAL. I guess this is coming from the limitation of BIO_MAX_VECS as 256. Since this was working on older kernels, did anything change in this regard?
The failing command was attempting to transfer a length of ~320K. It seems that nvme-cli does not split the transfers and sends the full transfer length to the kernel.
Thanks,
Avinash
On 16/05/25, 8:12 PM, "Keith Busch" <kbusch at kernel.org <mailto:kbusch at kernel.org>> wrote:
On Fri, May 16, 2025 at 12:49:07PM +0000, Avinash M N wrote:
> The device MDTS value is 2 MB. The same commands and device works fine on older kernels. The testing was on 5.14.
Not sure then. You may have to trace into the kernel to see where it's
getting the EINVAL error from.
And if you respond, please use plain text so that the mailing list
thread doesn't have gaps.
More information about the Linux-nvme
mailing list