nvme nvme0: I/O 0 (I/O Cmd) QID 1 timeout, aborting, source drive corruption observed

J. Hart jfhart085 at gmail.com
Thu Dec 15 01:07:32 PST 2022


On 12/15/22 5:23 PM, Christoph Hellwig wrote:
>>
>> dmesg reports the following:
> 
> nvme0 is the destination driver I guess?

That is correct.  The device /dev/nvme0n1p3 is the destination partition 
on the NVME drive, and was mounted at /mnt/root_new.

>> [Dec14 19:24] nvme nvme0: I/O 0 (I/O Cmd) QID 1 timeout, aborting
> 
> Can you enable CONFIG_NVME_VERBOSE_ERRORS so that we can see what
> commands are hanging?

I will do this and run the requisite testing right away.  I'll reply 
with the results as soon as I have them.

>> I have also observed file system corruption on the source drive of the
>> transfer.  I would not normally think this to be related, except that after
>> the first time I observed it, I made certain that I corrected the file
>> content before any additional attempts, but have seen this again after
>> every attempt.  The modification dates and file sizes did not change, but
>> the file content on the source drive did.  I confirmed this using the
>> "diff" utility, and again using a rsync dry run with the check sum test
>> enabled.

I should also note that I did a third test using md5sum and confirmed 
that the sums obtained thereby were different.

> Ok, that's really odd.  The only way I could think of that happening
> is if the driver does stay DMAs, which would be really grave.

My apologies....I am not sure what is meant by "stay DMAs".  Is there 
something I can look for here ?

> Do you have CONFIG_INTEL_IOMMU and CONFIG_INTEL_IOMMU_DEFAULT_ON enabled?
> If not, it would be good to enable those to see if the iommu catches
> any stray DMAs.

I will enable these as well and reply with the test results.  Thanks 
very much for your generous assistance.

J. Hart



More information about the Linux-nvme mailing list