From: "Belanger, Martin" <Martin.Belanger@dell.com>
To: Sagi Grimberg <sagi@grimberg.me>, 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>
Subject: RE: [bug report][bisected] blktests nvme/tcp nvme/030 failed on latest linux-block/for-next
Date: Thu, 11 Aug 2022 12:32:00 +0000 [thread overview]
Message-ID: <SJ0PR19MB4544D2851FADC899DBDEF9EAF2649@SJ0PR19MB4544.namprd19.prod.outlook.com> (raw)
In-Reply-To: <8a510b95-96e3-433e-221e-ffff06e04cf6@grimberg.me>
> -----Original Message-----
> From: Sagi Grimberg <sagi@grimberg.me>
> Sent: Thursday, August 11, 2022 8:28 AM
> To: Belanger, Martin; Yi Zhang
> Cc: linux-block; open list:NVM EXPRESS DRIVER; Chaitanya Kulkarni
> Subject: Re: [bug report][bisected] blktests nvme/tcp nvme/030 failed on
> latest linux-block/for-next
>
>
> [EXTERNAL EMAIL]
>
>
> >>>>>>>> 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://urldefense.com/v3/__https://lore.kernel.org/r/20220627080650
> >>> .1
> >>> 08936-1-
> >> sagi@grimberg.me__;!!LpKI!lYFKeBqI0lmp0AycSrZ6krKxEMUNjSwCO-tY
> >>> -FyMAu5KLid5bBqYpfEBGaRgfGtk1c3HLXUekSSPXr6pKw$
> >>> [lore[.]kernel[.]org]
> >>
> >> 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?
> >
> > Hi Sagi. We had a discussion regarding this back in January (or February?).
> >
> > I needed such an event on a reconnect for my project, nvme-stas:
> > https://urldefense.com/v3/__https://github.com/linux-nvme/nvme-stas__;
> > !!LpKI!irX6S76eib64xSu731DcJWqFyHakPIhRLmgFr0znASmf1y7sNmuQuYQrx
> -_t5Ks
> > 4Zz0q1d9Scr_JY9RM4g$ [github[.]com]
> >
> > This event was needed so that the host could re-register with a CDC on
> > a reconnect (per TP8010). At your suggestion, I added
> "NVME_EVENT=connected"
> > in host/core.c. This has been working great for me. Maybe the udev
> > rule could be modified to look for this event.
>
> That is exactly what it does, that is why nvme discover unexpectedly connects
> to all log entries, because the udev event triggers..
>
> In order to address the problem of missed AEN while controller was
> disconnected, we need to re-issue the log-page on a re-conect, not a first
> connect.
Ah! Got it. Sorry for the noise. -Martin
prev parent reply other threads:[~2022-08-11 12:32 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
2022-08-11 11:31 ` Belanger, Martin
2022-08-11 12:28 ` Sagi Grimberg
2022-08-11 12:32 ` Belanger, Martin [this message]
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=SJ0PR19MB4544D2851FADC899DBDEF9EAF2649@SJ0PR19MB4544.namprd19.prod.outlook.com \
--to=martin.belanger@dell.com \
--cc=chaitanyak@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--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.