On Wed, Aug 01, 2018 at 02:06:11PM +0200, Johannes Thumshirn wrote: > On Wed, Aug 01, 2018 at 08:00:44PM +0800, Ming Lei wrote: > > On Wed, Aug 01, 2018 at 07:52:19PM +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. > > > > Seems related with sr: > > > > 1) with scsi-mq > > [ 2.808204] ata2.01: NODEV after polling detection > > [ 2.809807] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 > > [ 2.827377] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 > > > > 2) without scsi_mq > > [ 5.549135] ata2.01: NODEV after polling detection > > [ 5.554404] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 > > [ 5.596143] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 > > [ 5.637126] sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray > > [ 5.637870] cdrom: Uniform CD-ROM driver Revision: 3.20 > > [ 5.648940] sr 1:0:0:0: Attached scsi CD-ROM sr0 > > [ 5.661605] sr 1:0:0:0: Attached scsi generic sg0 type 5 > > > > > > We may need to take a look at recent SCSI change. > > [ 2.052168] ata2.01: NODEV after polling detection > [ 2.053690] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 > [ 2.072269] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ P5 > [ 2.107220] sr 1:0:0:0: [sr0] scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray > [ 2.107675] cdrom: Uniform CD-ROM driver Revision: 3.20 > [ 2.111851] sr 1:0:0:0: Attached scsi CD-ROM sr0 > [ 2.123560] sr 1:0:0:0: Attached scsi generic sg0 type 5 > > # cat /proc/cmdline > console=ttyS0,115200 root=/dev/ram0 debug verbose > > $ grep SCSI_MQ .config > CONFIG_SCSI_MQ_DEFAULT=y > > on Martin's latest 4.19/scsi-queue. I just checked my daily test log, looks this issue is reported 1st time on next-20180731. Thanks, Ming
