On 09/30/2015 06:21 AM, Hannes Reinecke wrote: > On 09/29/2015 08:29 PM, Bart Van Assche wrote: >> On 09/29/2015 03:47 AM, Hannes Reinecke wrote: >>> here the next round of my update to the ALUA device handler. >> >> Sorry but this with this version I see an initiator kernel lockup >> shortly after the initiator system had been booted. I have attached >> the output of echo t > /proc/sysrq-trigger to this e-mail. >> > Hmm. Weird. > Everything seems to wait for alua_rtpg() to complete: [ ... ] Hello Hannes, Would it be possible to add the patch to your tree that causes scsi_dh_alua to be loaded automatically again (http://thread.gmane.org/gmane.linux.scsi/105276) ? I might have forgotten to load the scsi_dh_alua driver manually before I ran my test ... However, even with the scsi_dh_alua driver loaded a kernel lockup is reported. Please note that I do not know whether or not that lockup is related to this patch series or to the changes in v4.3-rc1: INFO: task srp_daemon:600 blocked for more than 120 seconds. Not tainted 4.3.0-rc1-debug+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. srp_daemon D ffff88045c6a2d00 0 600 593 0x00000000 ffff88043060b960 0000000000000092 ffffffff810ba0bd ffff88047fc95ad8 ffff88045c6a2d00 ffff880430559680 ffff88043060c000 ffff8804181061c8 ffff88041dbd3cf8 ffff8804181055e8 ffff880418104ad0 ffff88043060b978 Call Trace: [<ffffffff810ba0bd>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff814efcda>] schedule+0x3a/0x90 [<ffffffff81271a46>] blk_mq_freeze_queue_wait+0x56/0xb0 [<ffffffff810b45c0>] ? prepare_to_wait_event+0xf0/0xf0 [<ffffffff81273a61>] blk_mq_update_tag_set_depth+0x41/0xb0 [<ffffffff81274294>] blk_mq_init_allocated_queue+0x7c4/0x860 [<ffffffff8127436a>] blk_mq_init_queue+0x3a/0x60 [<ffffffffa0016a6c>] scsi_mq_alloc_queue+0x1c/0x50 [scsi_mod] [<ffffffffa0017c51>] scsi_alloc_sdev+0x331/0x3b0 [scsi_mod] [<ffffffffa0018554>] scsi_probe_and_add_lun+0x884/0xd20 [scsi_mod] [<ffffffffa00191cb>] __scsi_scan_target+0x52b/0x5f0 [scsi_mod] [<ffffffff8139198c>] ? __pm_runtime_resume+0x5c/0x80 [<ffffffffa001936c>] scsi_scan_target+0xdc/0x100 [scsi_mod] [<ffffffffa04374ae>] srp_create_target+0xfde/0x1410 [ib_srp] [<ffffffff810b8201>] ? match_held_lock+0x1c1/0x200 [<ffffffff81381b68>] dev_attr_store+0x18/0x30 [<ffffffff812300f4>] sysfs_kf_write+0x44/0x60 [<ffffffff8122f724>] kernfs_fop_write+0x144/0x190 [<ffffffff811b8788>] __vfs_write+0x28/0xe0 [<ffffffff810b6a4a>] ? percpu_down_read+0x5a/0x90 [<ffffffff811bba70>] ? __sb_start_write+0xe0/0x100 [<ffffffff811bba70>] ? __sb_start_write+0xe0/0x100 [<ffffffff811d7455>] ? __fget+0x5/0x210 [<ffffffff811b8e19>] vfs_write+0xa9/0x190 [<ffffffff811b9b19>] SyS_write+0x49/0xa0 [<ffffffff814f57b6>] entry_SYSCALL_64_fastpath+0x16/0x7a 7 locks held by srp_daemon/600: #0: (&f->f_pos_lock){+.+.+.}, at: [<ffffffff811d84b3>] __fdget_pos+0x43/0x50 #1: (sb_writers#3){.+.+.+}, at: [<ffffffff811bba70>] __sb_start_write+0xe0/0x100 #2: (&of->mutex){+.+.+.}, at: [<ffffffff8122f646>] kernfs_fop_write+0x66/0x190 #3: (s_active#142){.+.+.+}, at: [<ffffffff8122f64e>] kernfs_fop_write+0x6e/0x190 #4: (&host->add_target_mutex){+.+.+.}, at: [<ffffffffa043660b>] srp_create_target+0x13b/0x1410 [ib_srp] #5: (&shost->scan_mutex){+.+.+.}, at: [<ffffffffa0019317>] scsi_scan_target+0x87/0x100 [scsi_mod] #6: (&set->tag_list_lock){+.+...}, at: [<ffffffff81274272>] blk_mq_init_allocated_queue+0x7a2/0x860 Thanks, Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
