On 2019-01-10 6:22 p.m., Bart Van Assche wrote:
Hi Doug, Have you ever tried to run the libiscsi conformance tests against the scsi_debug driver? I tried the following: modprobe scsi_debug delay=0 max_luns=3 dev=$(for f in /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/[0-9]*/block/*; do echo $f; break; done) dev=/dev/$(basename $dev) libiscsi/test-tool/iscsi-test-cu --dataloss --allow-sanitize "$dev" That test triggers the following output: BUG: unable to handle kernel paging request at ffffa8d741235e00 PGD 13b141067 P4D 13b141067 PUD 13b146067 PMD 6fc5a067 PTE 0 Oops: 0002 [#1] SMP PTI CPU: 3 PID: 4967 Comm: iscsi-test-cu Not tainted 4.18.0-13-generic #14-Ubuntu Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10
Since memory corruption errors have been found elsewhere in lk 5.0-rc1 and a fix looks like it is pending, I will leave this one alone as I can't replicate it. Doug Gilbert
Code: ff ff ff 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe Call Trace: sg_copy_to_buffer+0x12/0x20 fetch_to_dev_buffer+0x4a/0x60 [scsi_debug] resp_write_same.part.35+0x125/0x190 [scsi_debug] resp_write_same_16+0x84/0xe0 [scsi_debug] schedule_resp+0x4b/0x790 [scsi_debug] scsi_debug_queuecommand+0x218/0x9c0 [scsi_debug] scsi_dispatch_cmd+0x98/0x230 scsi_queue_rq+0x4dc/0x5b0 blk_mq_dispatch_rq_list+0x93/0x4f0 blk_mq_do_dispatch_ctx+0xcd/0x130 blk_mq_sched_dispatch_requests+0x156/0x190 __blk_mq_run_hw_queue+0x57/0xe0 __blk_mq_delay_run_hw_queue+0x14d/0x160 blk_mq_run_hw_queue+0x5a/0x120 blk_mq_sched_insert_request+0x11d/0x180 blk_execute_rq_nowait+0x6f/0x100 blk_execute_rq+0x50/0xb0 sg_io+0x199/0x410 scsi_cmd_ioctl+0x1b9/0x3f0 scsi_cmd_blk_ioctl+0x51/0x61 sd_ioctl+0xcd/0x1c0 blkdev_ioctl+0x3b8/0x980 block_ioctl+0x3d/0x50 do_vfs_ioctl+0xa8/0x620 ksys_ioctl+0x67/0x90 __x64_sys_ioctl+0x1a/0x20 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Is this reproducible on your test setup? Thanks, Bart.
