* can't run nvme-mp blktests @ 2022-04-13 0:24 Luis Chamberlain 2022-04-13 3:02 ` Yi Zhang ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Luis Chamberlain @ 2022-04-13 0:24 UTC (permalink / raw) To: bvanassche, yi.zhang, sagi; +Cc: Luis Chamberlain, linux-block, linux-nvme I do have CONFIG_NVME_MULTIPATH=y but I also have: cat /etc/modprobe.d/nvme.conf options nvme_core multipath=N And yet I always end up booting with: cat /sys/module/nvme_core/parameters/multipath Y So trying to run: nvme_trtype=rdma ./check nvmeof-mp I end up with the warning: nvmeof-mp/*** [not run] CONFIG_NVME_MULTIPATH has been set in .config and multipathing has been enabled in the nvme_core kernel module Are there times where one cannot disable multipath? I'm not using any nvme drive at boot, but I do use one for a random data parition. Any tips? Luis ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 0:24 can't run nvme-mp blktests Luis Chamberlain @ 2022-04-13 3:02 ` Yi Zhang 2022-04-13 17:38 ` Luis Chamberlain 2022-04-13 4:53 ` Christoph Hellwig 2022-04-13 5:53 ` Bart Van Assche 2 siblings, 1 reply; 19+ messages in thread From: Yi Zhang @ 2022-04-13 3:02 UTC (permalink / raw) To: Luis Chamberlain Cc: Bart Van Assche, Sagi Grimberg, linux-block, open list:NVM EXPRESS DRIVER On Wed, Apr 13, 2022 at 8:24 AM Luis Chamberlain <mcgrof@kernel.org> wrote: > > I do have CONFIG_NVME_MULTIPATH=y but I also have: > > cat /etc/modprobe.d/nvme.conf > options nvme_core multipath=N > > And yet I always end up booting with: > > cat /sys/module/nvme_core/parameters/multipath > Y > > So trying to run: > > nvme_trtype=rdma ./check nvmeof-mp > > I end up with the warning: > > nvmeof-mp/*** [not run] > CONFIG_NVME_MULTIPATH has been set in .config and multipathing has been enabled in the nvme_core kernel module > > Are there times where one cannot disable multipath? I'm not using > any nvme drive at boot, but I do use one for a random data parition. So the multipath is not updated with N, pls try manually removing the nvme_core module and retest. Or just reboot can also help update the parameter. BTW, to run blktests nvmeof-mp, the correct way is: # ./check nvmeof-mp # use_siw=1 ./check nvmeof-mp > > Any tips? > > Luis > -- Best Regards, Yi Zhang ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 3:02 ` Yi Zhang @ 2022-04-13 17:38 ` Luis Chamberlain 0 siblings, 0 replies; 19+ messages in thread From: Luis Chamberlain @ 2022-04-13 17:38 UTC (permalink / raw) To: Yi Zhang Cc: Bart Van Assche, Sagi Grimberg, linux-block, open list:NVM EXPRESS DRIVER On Wed, Apr 13, 2022 at 11:02:47AM +0800, Yi Zhang wrote: > On Wed, Apr 13, 2022 at 8:24 AM Luis Chamberlain <mcgrof@kernel.org> wrote: > > > > I do have CONFIG_NVME_MULTIPATH=y but I also have: > > > > cat /etc/modprobe.d/nvme.conf > > options nvme_core multipath=N > > > > And yet I always end up booting with: > > > > cat /sys/module/nvme_core/parameters/multipath > > Y > > > > So trying to run: > > > > nvme_trtype=rdma ./check nvmeof-mp > > > > I end up with the warning: > > > > nvmeof-mp/*** [not run] > > CONFIG_NVME_MULTIPATH has been set in .config and multipathing has been enabled in the nvme_core kernel module > > > > Are there times where one cannot disable multipath? I'm not using > > any nvme drive at boot, but I do use one for a random data parition. > > So the multipath is not updated with N, pls try manually removing the > nvme_core module and retest. I can't remove the module as a filesystem is mounted on one of the nvme drives used at boot. It is not an OS partition, ie, it is just /data/. The blktests is intended for some other nvme drives. > Or just reboot can also help update the parameter. Reboot does not help, that is my point. > BTW, to run blktests nvmeof-mp, the correct way is: > # ./check nvmeof-mp > # use_siw=1 ./check nvmeof-mp That does not let me do anything different as CONFIG_NVME_MULTIPATH is still found to be set and the module parameter for nvme_core for multipath is still "Y". Luis ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 0:24 can't run nvme-mp blktests Luis Chamberlain 2022-04-13 3:02 ` Yi Zhang @ 2022-04-13 4:53 ` Christoph Hellwig 2022-04-13 17:38 ` Luis Chamberlain 2022-04-13 5:53 ` Bart Van Assche 2 siblings, 1 reply; 19+ messages in thread From: Christoph Hellwig @ 2022-04-13 4:53 UTC (permalink / raw) To: Luis Chamberlain; +Cc: bvanassche, yi.zhang, sagi, linux-block, linux-nvme On Tue, Apr 12, 2022 at 05:24:04PM -0700, Luis Chamberlain wrote: > I do have CONFIG_NVME_MULTIPATH=y but I also have: I'd suggest to ignore broken tests that require a deprecated option that will eventually be removed. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 4:53 ` Christoph Hellwig @ 2022-04-13 17:38 ` Luis Chamberlain 2022-04-13 17:41 ` Christoph Hellwig 0 siblings, 1 reply; 19+ messages in thread From: Luis Chamberlain @ 2022-04-13 17:38 UTC (permalink / raw) To: Christoph Hellwig; +Cc: bvanassche, yi.zhang, sagi, linux-block, linux-nvme On Tue, Apr 12, 2022 at 09:53:12PM -0700, Christoph Hellwig wrote: > On Tue, Apr 12, 2022 at 05:24:04PM -0700, Luis Chamberlain wrote: > > I do have CONFIG_NVME_MULTIPATH=y but I also have: > > I'd suggest to ignore broken tests that require a deprecated option > that will eventually be removed. CONFIG_NVME_MULTIPATH will eventually be nuked? Luis ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 17:38 ` Luis Chamberlain @ 2022-04-13 17:41 ` Christoph Hellwig 2022-04-13 18:12 ` Luis Chamberlain 2022-04-13 22:46 ` Bart Van Assche 0 siblings, 2 replies; 19+ messages in thread From: Christoph Hellwig @ 2022-04-13 17:41 UTC (permalink / raw) To: Luis Chamberlain Cc: Christoph Hellwig, bvanassche, yi.zhang, sagi, linux-block, linux-nvme On Wed, Apr 13, 2022 at 10:38:50AM -0700, Luis Chamberlain wrote: > On Tue, Apr 12, 2022 at 09:53:12PM -0700, Christoph Hellwig wrote: > > On Tue, Apr 12, 2022 at 05:24:04PM -0700, Luis Chamberlain wrote: > > > I do have CONFIG_NVME_MULTIPATH=y but I also have: > > > > I'd suggest to ignore broken tests that require a deprecated option > > that will eventually be removed. > > CONFIG_NVME_MULTIPATH will eventually be nuked? You'll only get a single namespace without it once the phaseout is complete, yes. If you want nvme multipathing you'll need it, which is the story since day one. If Bart wants to test dm-multipath I think his earlier srp_tests are the much better choice. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 17:41 ` Christoph Hellwig @ 2022-04-13 18:12 ` Luis Chamberlain 2022-04-15 5:22 ` Christoph Hellwig 2022-04-13 22:46 ` Bart Van Assche 1 sibling, 1 reply; 19+ messages in thread From: Luis Chamberlain @ 2022-04-13 18:12 UTC (permalink / raw) To: Christoph Hellwig; +Cc: bvanassche, yi.zhang, sagi, linux-block, linux-nvme On Wed, Apr 13, 2022 at 10:41:12AM -0700, Christoph Hellwig wrote: > On Wed, Apr 13, 2022 at 10:38:50AM -0700, Luis Chamberlain wrote: > > On Tue, Apr 12, 2022 at 09:53:12PM -0700, Christoph Hellwig wrote: > > > On Tue, Apr 12, 2022 at 05:24:04PM -0700, Luis Chamberlain wrote: > > > > I do have CONFIG_NVME_MULTIPATH=y but I also have: > > > > > > I'd suggest to ignore broken tests that require a deprecated option > > > that will eventually be removed. > > > > CONFIG_NVME_MULTIPATH will eventually be nuked? > > You'll only get a single namespace without it once the phaseout is > complete, yes. OK so CONFIG_NVME_MULTIPATH will be nuked, but the module parameter will remain, and if the module parameter is used with multipath=N you'll end up with a single namespace once the phase out of CONFIG_NVME_MULTIPATH is complete. > If you want nvme multipathing you'll need it, which > is the story since day one. Sounds good. > If Bart wants to test dm-multipath I think his earlier srp_tests are > the much better choice. OK thanks for the heads up. Luis ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 18:12 ` Luis Chamberlain @ 2022-04-15 5:22 ` Christoph Hellwig 0 siblings, 0 replies; 19+ messages in thread From: Christoph Hellwig @ 2022-04-15 5:22 UTC (permalink / raw) To: Luis Chamberlain Cc: Christoph Hellwig, bvanassche, yi.zhang, sagi, linux-block, linux-nvme On Wed, Apr 13, 2022 at 11:12:26AM -0700, Luis Chamberlain wrote: > OK so CONFIG_NVME_MULTIPATH will be nuked, but the module parameter > will remain, and if the module parameter is used with multipath=N you'll > end up with a single namespace once the phase out of > CONFIG_NVME_MULTIPATH is complete. The other way around. The plan is that CONFIG_NVME_MULTIPATH will stay around forever - for deeply embedded devices that only have a soldered on or sd-card nvme device with a single path there is no need to carry the multipathing code around. But the code to support multiple controllers in a subsystem without CONFIG_NVME_MULTIPATH will go away. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 17:41 ` Christoph Hellwig 2022-04-13 18:12 ` Luis Chamberlain @ 2022-04-13 22:46 ` Bart Van Assche 2022-04-15 5:20 ` Christoph Hellwig 1 sibling, 1 reply; 19+ messages in thread From: Bart Van Assche @ 2022-04-13 22:46 UTC (permalink / raw) To: Christoph Hellwig, Luis Chamberlain Cc: yi.zhang, sagi, linux-block, linux-nvme On 4/13/22 10:41, Christoph Hellwig wrote: > On Wed, Apr 13, 2022 at 10:38:50AM -0700, Luis Chamberlain wrote: >> On Tue, Apr 12, 2022 at 09:53:12PM -0700, Christoph Hellwig wrote: >>> On Tue, Apr 12, 2022 at 05:24:04PM -0700, Luis Chamberlain wrote: >>>> I do have CONFIG_NVME_MULTIPATH=y but I also have: >>> >>> I'd suggest to ignore broken tests that require a deprecated option >>> that will eventually be removed. >> >> CONFIG_NVME_MULTIPATH will eventually be nuked? > > You'll only get a single namespace without it once the phaseout is > complete, yes. If you want nvme multipathing you'll need it, which > is the story since day one. > > If Bart wants to test dm-multipath I think his earlier srp_tests are > the much better choice. I'm not sure whether the nvme-mp tests test any code that is not yet tested by any nvme or srp test. How about removing these tests since these tests make it harder than necessary to run blktests? Thanks, Bart. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 22:46 ` Bart Van Assche @ 2022-04-15 5:20 ` Christoph Hellwig 2022-04-15 5:58 ` Chaitanya Kulkarni 0 siblings, 1 reply; 19+ messages in thread From: Christoph Hellwig @ 2022-04-15 5:20 UTC (permalink / raw) To: Bart Van Assche Cc: Christoph Hellwig, Luis Chamberlain, yi.zhang, sagi, linux-block, linux-nvme On Wed, Apr 13, 2022 at 03:46:16PM -0700, Bart Van Assche wrote: > I'm not sure whether the nvme-mp tests test any code that is not yet tested by > any nvme or srp test. How about removing these tests since these tests make > it harder than necessary to run blktests? I haven't looked at the details recently, but if these tests still are basically a copy and paste of the srp mpath tests I'm all for removing them! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-15 5:20 ` Christoph Hellwig @ 2022-04-15 5:58 ` Chaitanya Kulkarni 2022-04-15 17:59 ` Luis Chamberlain 2022-04-15 18:06 ` Bart Van Assche 0 siblings, 2 replies; 19+ messages in thread From: Chaitanya Kulkarni @ 2022-04-15 5:58 UTC (permalink / raw) To: Christoph Hellwig, Bart Van Assche Cc: Luis Chamberlain, yi.zhang, sagi, linux-block, linux-nvme On 4/14/22 22:20, Christoph Hellwig wrote: > On Wed, Apr 13, 2022 at 03:46:16PM -0700, Bart Van Assche wrote: >> I'm not sure whether the nvme-mp tests test any code that is not yet tested by >> any nvme or srp test. How about removing these tests since these tests make >> it harder than necessary to run blktests? > > I haven't looked at the details recently, but if these tests still are > basically a copy and paste of the srp mpath tests I'm all for removing > them! If it doesn't add a new test coverage in the blktest framework then please remove. -ck ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-15 5:58 ` Chaitanya Kulkarni @ 2022-04-15 17:59 ` Luis Chamberlain 2022-04-15 18:09 ` Bart Van Assche 2022-04-15 18:06 ` Bart Van Assche 1 sibling, 1 reply; 19+ messages in thread From: Luis Chamberlain @ 2022-04-15 17:59 UTC (permalink / raw) To: Chaitanya Kulkarni Cc: Christoph Hellwig, Bart Van Assche, yi.zhang, sagi, linux-block, linux-nvme On Fri, Apr 15, 2022 at 05:58:16AM +0000, Chaitanya Kulkarni wrote: > On 4/14/22 22:20, Christoph Hellwig wrote: > > On Wed, Apr 13, 2022 at 03:46:16PM -0700, Bart Van Assche wrote: > >> I'm not sure whether the nvme-mp tests test any code that is not yet tested by > >> any nvme or srp test. How about removing these tests since these tests make > >> it harder than necessary to run blktests? > > > > I haven't looked at the details recently, but if these tests still are > > basically a copy and paste of the srp mpath tests I'm all for removing > > them! > > If it doesn't add a new test coverage in the blktest framework > then please remove. That's about 3 block folks not being sure whether or not it helps. And the complexities of it, to test it, requiring a different kernel seems just stupid. So I'm going to drop the tests from kdevops and not bother with them. With regards to srp tests there seems to be two modules to use. Do we want to prioritize both just as much? If so then I'll just create two guests for srp tests. Luis ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-15 17:59 ` Luis Chamberlain @ 2022-04-15 18:09 ` Bart Van Assche 2022-04-20 10:36 ` Hannes Reinecke 2022-04-21 17:56 ` Luis Chamberlain 0 siblings, 2 replies; 19+ messages in thread From: Bart Van Assche @ 2022-04-15 18:09 UTC (permalink / raw) To: Luis Chamberlain, Chaitanya Kulkarni Cc: Christoph Hellwig, yi.zhang, sagi, linux-block, linux-nvme On 4/15/22 10:59, Luis Chamberlain wrote: > That's about 3 block folks not being sure whether or not it helps. And > the complexities of it, to test it, requiring a different kernel seems > just stupid. So I'm going to drop the tests from kdevops and not bother > with them. How about modifying the nvmeof-mp tests such that these use NVMe multipathing instead of the dm-multipath driver? > With regards to srp tests there seems to be two modules to use. Do we > want to prioritize both just as much? If so then I'll just create two > guests for srp tests. The rdma_rxe driver is older than the siw (Soft-iWARP) driver. That's why the rdma_rxe driver is the default for the SRP tests. Ideally it shouldn't matter whether the rdma_rxe or the siw driver is used for the SRP tests. There has been a time when the rdma_rxe driver worked perfectly when running the SRP tests. Unfortunately that is no longer the case ... Thanks, Bart. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-15 18:09 ` Bart Van Assche @ 2022-04-20 10:36 ` Hannes Reinecke 2022-04-21 17:56 ` Luis Chamberlain 1 sibling, 0 replies; 19+ messages in thread From: Hannes Reinecke @ 2022-04-20 10:36 UTC (permalink / raw) To: Bart Van Assche, Luis Chamberlain, Chaitanya Kulkarni Cc: Christoph Hellwig, yi.zhang, sagi, linux-block, linux-nvme On 4/15/22 20:09, Bart Van Assche wrote: > On 4/15/22 10:59, Luis Chamberlain wrote: >> That's about 3 block folks not being sure whether or not it helps. And >> the complexities of it, to test it, requiring a different kernel seems >> just stupid. So I'm going to drop the tests from kdevops and not bother >> with them. > > How about modifying the nvmeof-mp tests such that these use NVMe > multipathing instead of the dm-multipath driver? > I'd rather enable the nvme tests to work with rdma_rxe / siw. It should already work with TCP, so hooking in rdma_rxe and/or siw would be the logical step. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-15 18:09 ` Bart Van Assche 2022-04-20 10:36 ` Hannes Reinecke @ 2022-04-21 17:56 ` Luis Chamberlain 1 sibling, 0 replies; 19+ messages in thread From: Luis Chamberlain @ 2022-04-21 17:56 UTC (permalink / raw) To: Bart Van Assche Cc: Chaitanya Kulkarni, Christoph Hellwig, yi.zhang, sagi, linux-block, linux-nvme On Fri, Apr 15, 2022 at 11:09:33AM -0700, Bart Van Assche wrote: > On 4/15/22 10:59, Luis Chamberlain wrote: > > That's about 3 block folks not being sure whether or not it helps. And > > the complexities of it, to test it, requiring a different kernel seems > > just stupid. So I'm going to drop the tests from kdevops and not bother > > with them. > > How about modifying the nvmeof-mp tests such that these use NVMe > multipathing instead of the dm-multipath driver? Patches welcomed, I'm just going to ignore nvme-mp for now. Luis ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-15 5:58 ` Chaitanya Kulkarni 2022-04-15 17:59 ` Luis Chamberlain @ 2022-04-15 18:06 ` Bart Van Assche 2022-04-20 10:29 ` Hannes Reinecke 1 sibling, 1 reply; 19+ messages in thread From: Bart Van Assche @ 2022-04-15 18:06 UTC (permalink / raw) To: Chaitanya Kulkarni, Christoph Hellwig Cc: Luis Chamberlain, yi.zhang, sagi, linux-block, linux-nvme On 4/14/22 22:58, Chaitanya Kulkarni wrote: > If it doesn't add a new test coverage in the blktest framework > then please remove. cd blktests && git grep -nH dev/nvme-fabrics tests/nvmeof-mp/rc:94: [ -c /dev/nvme-fabrics ] && tests/nvmeof-mp/rc:101: echo -n "$loginparams" > /dev/nvme-fabrics tests/nvmeof-mp/rc:161: if [ ! -c /dev/nvme-fabrics ]; then tests/nvmeof-mp/rc:162: echo "Error: /dev/nvme-fabrics not available" Does this mean that there are no other tests in the blktests framework that test NVMeOF and hence that it is useful to keep these tests? Thanks, Bart. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-15 18:06 ` Bart Van Assche @ 2022-04-20 10:29 ` Hannes Reinecke 0 siblings, 0 replies; 19+ messages in thread From: Hannes Reinecke @ 2022-04-20 10:29 UTC (permalink / raw) To: Bart Van Assche, Chaitanya Kulkarni, Christoph Hellwig Cc: Luis Chamberlain, yi.zhang, sagi, linux-block, linux-nvme On 4/15/22 20:06, Bart Van Assche wrote: > On 4/14/22 22:58, Chaitanya Kulkarni wrote: >> If it doesn't add a new test coverage in the blktest framework >> then please remove. > > cd blktests && git grep -nH dev/nvme-fabrics > tests/nvmeof-mp/rc:94: [ -c /dev/nvme-fabrics ] && > tests/nvmeof-mp/rc:101: echo -n "$loginparams" > > /dev/nvme-fabrics > tests/nvmeof-mp/rc:161: if [ ! -c /dev/nvme-fabrics ]; then > tests/nvmeof-mp/rc:162: echo "Error: /dev/nvme-fabrics not > available" > > Does this mean that there are no other tests in the blktests framework that > test NVMeOF and hence that it is useful to keep these tests? > # git grep _nvme_connect_subsys tests/nvme/003: _nvme_connect_subsys "${nvme_trtype}" nqn.2014-08.org.nvmexpress.discovery tests/nvme/004: _nvme_connect_subsys "${nvme_trtype}" blktests-subsystem-1 tests/nvme/005: _nvme_connect_subsys "${nvme_trtype}" blktests-subsystem-1 tests/nvme/008: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/009: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/010: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/011: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/012: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/013: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/014: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/015: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/018: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/019: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/020: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" tests/nvme/021: _nvme_connect_subsys "${nvme_trtype}" "${subsys_name}" [ .. ] So: no, it just means you've been using the wrong filter. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 0:24 can't run nvme-mp blktests Luis Chamberlain 2022-04-13 3:02 ` Yi Zhang 2022-04-13 4:53 ` Christoph Hellwig @ 2022-04-13 5:53 ` Bart Van Assche 2022-04-13 18:08 ` Luis Chamberlain 2 siblings, 1 reply; 19+ messages in thread From: Bart Van Assche @ 2022-04-13 5:53 UTC (permalink / raw) To: Luis Chamberlain, yi.zhang, sagi; +Cc: linux-block, linux-nvme On 4/12/22 17:24, Luis Chamberlain wrote: > I do have CONFIG_NVME_MULTIPATH=y but I also have: > > cat /etc/modprobe.d/nvme.conf > options nvme_core multipath=N > > And yet I always end up booting with: > > cat /sys/module/nvme_core/parameters/multipath > Y Is the nvme_core module loaded from the initial ramdisk or from /lib/modules? In the former case, does the initial ramdisk perhaps have to be regenerated? Thanks, Bart. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: can't run nvme-mp blktests 2022-04-13 5:53 ` Bart Van Assche @ 2022-04-13 18:08 ` Luis Chamberlain 0 siblings, 0 replies; 19+ messages in thread From: Luis Chamberlain @ 2022-04-13 18:08 UTC (permalink / raw) To: Bart Van Assche; +Cc: yi.zhang, sagi, linux-block, linux-nvme On Tue, Apr 12, 2022 at 10:53:40PM -0700, Bart Van Assche wrote: > On 4/12/22 17:24, Luis Chamberlain wrote: > > I do have CONFIG_NVME_MULTIPATH=y but I also have: > > > > cat /etc/modprobe.d/nvme.conf > > options nvme_core multipath=N > > > > And yet I always end up booting with: > > > > cat /sys/module/nvme_core/parameters/multipath > > Y > > Is the nvme_core module loaded from the initial ramdisk or from > /lib/modules? In the former case, does the initial ramdisk perhaps have to > be regenerated? No, no ramdisk, but I just had to use the /etc/default/grub file to set nvme_core=N as the /etc/modprobe.d/nvme.conf was not being picked up for whatever reason. cat /etc/modprobe.d/nvme.conf options nvme_core multipath=N Either way, from a test automation perspective this requirement is a pain, as I can't do a change dynamically at run time. So for this test I have to manually change a kernel boot param. Is doing the required changes dynamic not possible in the future? I take it that it does not make sense at all to have multipath=N for all blktests tests. Luis ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-04-21 17:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-13 0:24 can't run nvme-mp blktests Luis Chamberlain 2022-04-13 3:02 ` Yi Zhang 2022-04-13 17:38 ` Luis Chamberlain 2022-04-13 4:53 ` Christoph Hellwig 2022-04-13 17:38 ` Luis Chamberlain 2022-04-13 17:41 ` Christoph Hellwig 2022-04-13 18:12 ` Luis Chamberlain 2022-04-15 5:22 ` Christoph Hellwig 2022-04-13 22:46 ` Bart Van Assche 2022-04-15 5:20 ` Christoph Hellwig 2022-04-15 5:58 ` Chaitanya Kulkarni 2022-04-15 17:59 ` Luis Chamberlain 2022-04-15 18:09 ` Bart Van Assche 2022-04-20 10:36 ` Hannes Reinecke 2022-04-21 17:56 ` Luis Chamberlain 2022-04-15 18:06 ` Bart Van Assche 2022-04-20 10:29 ` Hannes Reinecke 2022-04-13 5:53 ` Bart Van Assche 2022-04-13 18:08 ` Luis Chamberlain
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.