On 29/03/2019 01:33, Ming Lei wrote: [...] >> + blk_queue_segment_boundary(ctrl->ctrl.admin_q, PAGE_SIZE - 1); > > The above isn't needed for linus tree, however it is required for 5.0 and older > releases. Yes but it was worth a try after days of failing to find the issue. > But nvme-loop target have other problems, and I'd suggest you to apply > the following patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=for-linus&id=02db99548d3608a625cf481cff2bb7b626829b3f This only applies to the file backed target, doesn't it? My testcase uses bdev backed namespaces. [...] >> 731 >> 732 /* If we may be able to merge these biovecs, force a recount */ >> 733 if (bio->bi_vcnt > 1 && biovec_phys_mergeable(q, bvec - 1, bvec)) >> 734 bio->bi_phys_segments = -1; > > The above change from you might cause issue given some queue's .bi_phys_segments > is 255. 65535 but yes there are drivers setting it to USHRT_MAX. I'll have to see if I can get hold of one for testing. [...] > I'd suggest you to address the following comments first before working on > your patch: > > https://lore.kernel.org/linux-block/CACVXFVNPW1TOsCaAibc-YJHDEdK95Y8-v1rHNaab7oV=eb+8TA@xxxxxxxxxxxxxx/ > > https://lore.kernel.org/linux-block/CACVXFVOq1ngjpD62SreSZda5k_WJjxOZRHwpqt6si7bRv=O46Q@xxxxxxxxxxxxxx/ I'll have a look, thanks. [...] > Can you trigger this issue on linus tree or 5.2-tmp of block tree? I haven't been able to trigger it on vanilla so far, so it's most likely related to the patch. Will rebase the patchset to 5.2-tmp and retest from there. Thanks, Johannes -- Johannes Thumshirn SUSE Labs Filesystems jthumshirn@xxxxxxx +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
