From: "Rajashekar, Revanth" <revanth.rajashekar@intel.com>
To: Ingo Brunberg <ingo_brunberg@web.de>
Cc: "kbusch@kernel.org" <kbusch@kernel.org>,
"chaitanya.kulkarni@wdc.com" <chaitanya.kulkarni@wdc.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"sagi@grimberg.me" <sagi@grimberg.me>
Subject: Re: [PATCH] nvme: Namepace identification descriptor list is optional
Date: Sun, 12 Jul 2020 11:03:46 -0600 [thread overview]
Message-ID: <b58c192d-bd81-651a-ca9f-d614e4655e48@intel.com> (raw)
In-Reply-To: <m3k0z9nkpl.fsf@web.de>
On 7/12/2020 3:31 AM, Ingo Brunberg wrote:
> "Rajashekar, Revanth" <revanth.rajashekar@intel.com> writes:
>
>> Hi,
>>
>> On 7/10/2020 2:22 AM, Ingo Brunberg wrote:
>>
>> With commit ea43d97, appearing now in kernel 5.7.8, you made my
>> cheap
>> SSD disfunctional again. For reference, see bug 205679. Maybe you
>> remember the discussion.
>>
>> Shouldn't the logic used in commit ea43d97, be applied to the line 'if (ret == -ENOMEM || (ret > 0 &&
>> !(ret & NVME_SC_DNR)))' in function '_nvme_revalidate_disk' ?
> I was wondering the same. But that does not make my drive
> work. Something about that logic is not quite right. If the condition is
> met in nvme_identify_ns_descs, 0 is returned. So there is no point in
> repeating the same test in nvme_revalidate_disk as that code path is not
> reached anyway.
I agree with that... My concern is in case if the status had the DNR bit cleared.
In that case this line of the code is reached and the status is silently suppressed to 0 because of the condition !(ret & NVME_SC_DNR)
The intention of the commit ea43d97 was to navigate back the error in-case if it was a retryable error (DNR cleared to 0).
>
> If I got it right, NVME_SC_DNR is not set for my drive, so this test is
> not the right solution for that problematic controller.
>
> Regards
> Ingo Brunberg
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-07-12 17:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <d163890a-a469-e71c-45b7-f63e1efee04e@intel.com>
2020-07-12 9:31 ` [PATCH] nvme: Namepace identification descriptor list is optional Ingo Brunberg
2020-07-12 17:03 ` Rajashekar, Revanth [this message]
2020-07-14 15:21 ` Keith Busch
2019-12-02 15:56 Keith Busch
2019-12-02 16:15 ` Christoph Hellwig
2019-12-02 16:22 ` Keith Busch
2019-12-02 16:27 ` Nadolski, Edmund
2019-12-02 16:29 ` Christoph Hellwig
2019-12-02 16:45 ` Nadolski, Edmund
2019-12-02 16:49 ` Keith Busch
2019-12-02 17:34 ` Christoph Hellwig
2019-12-02 21:21 ` Keith Busch
2020-07-10 8:22 ` Ingo Brunberg
2020-07-22 23:23 ` Sagi Grimberg
2020-07-23 1:23 ` Ingo Brunberg
2020-07-28 11:08 ` Christoph Hellwig
2020-07-28 14:41 ` Ingo Brunberg
2020-07-28 16:01 ` Sagi Grimberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b58c192d-bd81-651a-ca9f-d614e4655e48@intel.com \
--to=revanth.rajashekar@intel.com \
--cc=chaitanya.kulkarni@wdc.com \
--cc=ingo_brunberg@web.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).