From: Sagi Grimberg <sagi@grimberg.me>
To: Yi Zhang <yi.zhang@redhat.com>
Cc: linux-block <linux-block@vger.kernel.org>,
"open list:NVM EXPRESS DRIVER" <linux-nvme@lists.infradead.org>,
Chaitanya Kulkarni <chaitanyak@nvidia.com>,
"Belanger, Martin" <Martin.Belanger@dell.com>
Subject: Re: [bug report][bisected] blktests nvme/tcp nvme/030 failed on latest linux-block/for-next
Date: Thu, 11 Aug 2022 12:36:08 +0300 [thread overview]
Message-ID: <53ed5142-f9ee-f373-25fc-69c14bc372b3@grimberg.me> (raw)
In-Reply-To: <CAHj4cs82ssuVX25yeHXhtqkkApxJbWDaoyOgq=0u5C4LWF2btg@mail.gmail.com>
>>>>>> nvme/030 triggered several errors during CKI tests on
>>>>>> linux-block/for-next, pls help check it, and feel free to let me
>>>>>> know if you need any test/info, thanks.
>>
>> Hi Chaitanya and Yi,
>>
>> This commit (submitted last February) simply exposes two read-only attributes
>> to the sysfs.
>
> Seems it was not the culprit, but nvme/030 can pass after I revert
> that commit on v5.19.
>
> Hi Sagi
>
> I did more testing and finally found that reverting this udev rule
> change in nvme-cli fix the nvme/030 failure issue, could you check
> it?
>
> commit f86faaaa2a1ff319bde188dc8988be1ec054d238 (refs/bisect/bad)
> Author: Sagi Grimberg <sagi@grimberg.m
> Date: Mon Jun 27 11:06:50 2022 +0300
>
> udev: re-read the discovery log page when a discovery controller reconnected
>
> When using persistent discovery controllers, if the discovery
> controller loses connectivity and manage to reconnect after a while,
> we need to retrieve again the discovery log page in order to learn
> about possible changes that may have occurred during this time as
> discovery log change events were lost.
>
> Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
> Signed-off-by: Daniel Wagner <dwagner@suse.de>
> Link: https://lore.kernel.org/r/20220627080650.108936-1-sagi@grimberg.me
Yes, this change is reverted now from nvme-cli...
I'm thinking how should we solve the original issue, the only way I can
think of at this moment is a "reconnected" event. Does anyone have an
idea how userspace can do the right thing here without it?
next prev parent reply other threads:[~2022-08-11 9:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 12:37 [bug report] blktests nvme/tcp nvme/030 failed on latest linux-block/for-next Yi Zhang
2022-08-03 16:43 ` [bug report][bisected] " Yi Zhang
2022-08-03 19:37 ` Chaitanya Kulkarni
2022-08-04 9:49 ` Yi Zhang
2022-08-04 18:06 ` Belanger, Martin
2022-08-05 1:54 ` Yi Zhang
2022-08-11 9:36 ` Sagi Grimberg [this message]
2022-08-11 11:31 ` Belanger, Martin
2022-08-11 12:28 ` Sagi Grimberg
2022-08-11 12:32 ` Belanger, Martin
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=53ed5142-f9ee-f373-25fc-69c14bc372b3@grimberg.me \
--to=sagi@grimberg.me \
--cc=Martin.Belanger@dell.com \
--cc=chaitanyak@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=yi.zhang@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.