On Apr 09, 2025 / 19:59, Daniel Wagner wrote:
> On Tue, Apr 08, 2025 at 06:25:59PM +0200, Daniel Wagner wrote:
> > +requires() {
> > + _nvme_requires
> > + _have_loop
> > + _require_nvme_trtype_is_fabrics
> > + _have_kernel_option NVME_TARGET_DEBUGF
>
> Typo: s/NVME_TARGET_DEBUGF/NVME_TARGET_DEBUGFS/
I can fold in this change.
BTW, when I ran this test case for tr=loop, I observe the kernel
message reports "invalid parameter" errors as follows:
[ 150.907272][ T2312] run blktests nvme/060 at 2025-04-14 20:59:00
[ 150.947249][ T2367] loop0: detected capacity change from 0 to 2097152
[ 150.959649][ T2370] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
[ 151.009708][ T2382] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[ 155.626630][ T2429] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[ 160.158015][ T2476] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[ 164.745460][ T2523] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[ 169.161893][ T2570] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
[ 173.766537][ T2619] nvme_fabrics: invalid parameter 'reconnect_delay=%d'
Is it expected?
This test case passes for other transports (rdma, tcp and fc) and they do not
trigger the error message above. My mere guess is that this case might not work
for the loop transport, and may need "_require_nvme_trtype tcp rdma fc" in same
manner as nvme/048.
