On Wed, Aug 01, 2018 at 07:52:21PM +0800, Ming Lei wrote: > On Wed, Aug 01, 2018 at 12:24:00PM +0100, Matt Hart wrote: > > On 1 August 2018 at 11:59, Mark Brown <broonie@xxxxxxxxxx> wrote: > > > On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote: > > > > > >> You may have to provide some clue, such as dmesg log, boot disk, ... > > > > > >> I guess you don't use virtio-scsi/virtio-blk since both run at blk-mq > > >> mode at default, even though without d5038a13eca72fb. > > > > > > Boot logs and so on can be found here: > > > > > > https://kernelci.org/boot/id/5b618c9f59b514931f96ba97/ > > > https://kernelci.org/boot/id/5b618ca359b514904d96bac5/ > > > https://kernelci.org/boot/id/5b618cbc59b51492e896baad/ > > > > > > (these are today's but the symptoms are the same.) The ramdisk is > > > unfortunately not linked through the UI, though we don't get that far. > > > > And a full LAVA boot log from my lab > > http://lava.streamtester.net/scheduler/job/138067 > > > > QEMU command line here: > > http://lava.streamtester.net/scheduler/job/138067#L75 > > > > And a LAVA job definition, which includes the url of the ramdisk and kernel: > > http://lava.streamtester.net/scheduler/job/138067/definition#defline76 > > > > Thanks for the sharing! > > I can reproduce this issue with above script/initrd/kernel config, and looks > the issue disappeared after 'scsi_mod.use_blk_mq=0' is passed. > > Not see such issue with zero-day ktest config. > > Looks a bit weird, given SCSI_MQ is nothing related with ramdisk. Ahm and: qemu [...] -append "console=ttyS0,115200 root=/dev/ram0 debug verbose" $ grep CONFIG_BLK_DEV_RAM .config # CONFIG_BLK_DEV_RAM is not set Something is fishy here. -- Johannes Thumshirn Storage jthumshirn@xxxxxxx +49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
