[bug report][bisected] blktests nvme/tcp nvme/030 failed on latest linux-block/for-next

Sagi Grimberg sagi at grimberg.me
Thu Aug 11 02:36:08 PDT 2022


>>>>>> 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 at 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 at grimberg.me>
>      Signed-off-by: Daniel Wagner <dwagner at 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?



More information about the Linux-nvme mailing list