On Fri, Mar 01 2019 at 12:33pm -0500, Michael Holzheu <holzheu@xxxxxxxxxxxxx> wrote: > Hi Mike, > > On Fedora 29, the following "linux-next" commit introduced a regression on s390: > > commit 1efa3bb79d3de8ca1b7f6770313a1fc0bebe25c7 > Author: Mike Snitzer <snitzer@xxxxxxxxxx> > Date: Fri Feb 22 11:23:01 2019 -0500 > > dm: must allocate dm_noclone for stacked noclone devices > > Otherwise various lvm2 testsuite tests fail because the lower layers of > the stacked noclone device aren't updated to allocate a new 'struct > dm_clone' that reflects the upper layer bio that was issued to it. > > Fixes: 97a89458020b38 ("dm: improve noclone bio support") > Reported-by: Mikulas Patocka <mpatocka@xxxxxxxxxx> > Signed-off-by: Mike Snitzer <snitzer@xxxxxxxxxx> > > With this commit the boot hangs three minutes on a z/VM system with the > following device mapper setup: > > # dmsetup ls --tree > mpathe (252:5) > ├─ (8:128) > └─ (8:144) > mpathd (252:4) > ├─ (8:96) > └─ (8:112) > mpathc (252:3) > ├─ (8:64) > └─ (8:80) > mpathb (252:2) > ├─ (8:32) > └─ (8:48) > mpatha1 (252:1) > └─mpatha (252:0) > ├─ (8:16) > └─ (8:0) > > On the console we get messages like the following: > > 10.116863 sd 3:0:0:1083719813: sdj Write Protect is off > 10.117170 sd 3:0:0:1083719813: sdj Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > 10.130562 sd 3:0:0:1083719813: sdj Attached SCSI disk > A start job is running for udev Wai Device Initialization (6s / 3min) > A start job is running for udev Wai Device Initialization (6s / 3min) > A start job is running for udev Wai Device Initialization (7s / 3min) > A start job is running for udev Wai Device Initialization (7s / 3min) > A start job is running for udev Wai Device Initialization (8s / 3min) > ... > > After three minutes the boot process continues and the system comes. > > As kernel config we used "performance_defconfig" (make performance_defconfig). I'm struggling to see why this particular change would cause such a boot stall -- but then resolve itself. Can you provide the output from 'dmsetup table'? Multipath defaults to blk-mq (request-based). The change you've called into question is related to bio-based DM. So There must be some bio-based DM layer ontop of the multipath devices. Is mpatha1 a dm-linear device layered ontop of multipath? Thanks, Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel