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@xxxxxxxxxxx>
Signed-off-by: Daniel Wagner <dwagner@xxxxxxx>
Link: https://lore.kernel.org/r/20220627080650.108936-1-sagi@xxxxxxxxxxx
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?
