[bug report]nvme0: Admin Cmd(0x6), I/O Error (sct 0x0 / sc 0x2) MORE DNR observed during blktests

Jonathan Derrick jonathan.derrick at linux.dev
Mon Apr 4 17:43:01 PDT 2022



On 4/4/2022 2:30 PM, Keith Busch wrote:
> On Mon, Apr 04, 2022 at 01:34:38PM -0600, Jonathan Derrick wrote:
>>
>>
>> On 4/4/2022 11:02 AM, Keith Busch wrote:
>>> On Mon, Apr 04, 2022 at 04:39:06PM +0000, Alan Adamson wrote:
>>>>
>>>> [   97.083215] nvme0: Admin Cmd(0x6), I/O Error (sct 0x0 / sc 0x2) MORE DNR
>>>>
>>>> An error from the device (status=2/Invalid Field) when an Identify (0x6) command was issued. Prior to the patch,
>>>> the nvme driver didn’t display the error.
>>> And it's harmless. The driver is querying an optional identification and it's
>>> okay if the device doesn't support it, but the driver doesn't know if the
>>> device supports until it tries it.
>> I've had to field bug reports like this before, where it says error in dmesg
>> but is actually harmless.
> 
> Even before the kernel message was added, some implementations trigger error
> log events, which alerts smartd. :(
I haven't had too many smartd reports come my way, but 'error' in dmesg 
is a typical one. Usually due a language barrier issue or uneducated AE. 
But I suspect a lay-user without an AE might resort to kernel bz due to 
things like this.

>   
>> Maybe we could suppress the error and add a harmless print?
>> Eg, nvme0: blah blah command set not supported
> 
> The new print in the completion handler is pretty generic. I don't think it can
> readily tell the difference from a harmless error. Maybe pr_err is too high?
Could we pack RQF_FAILED in the req flags and reduce the severity in 
nvme_log_error?

> 
> Or maybe since enough people have been concerned about *this* specific
> identify, maybe it should be restricted to 2.0 devices where it's mandatory. I
> was reluctant to do that at first since the initial device I tested was 1.4,
> but it was a prototype and we should be fine without the non-mdts limits
> anyway.
Well I'm not sure about that. I'm not honestly sure what this specific 
identify is, but (I know you know) NVMe being forward compatible allows 
eg, 1.4 compliant devices/targets to support 2.0 features.



More information about the Linux-nvme mailing list