On Fri, 2017-08-11 at 11:05 +1000, Michael Ellerman wrote: > kworker/u193:0 D12736 6 2 0x00000800 > Workqueue: events_unbound async_run_entry_fn > Call Trace: > [c0000003f7597410] [c000000000150d00] console_unlock+0x330/0x770 (unreliable) > [c0000003f75975e0] [c00000000001b3b8] __switch_to+0x2a8/0x460 > [c0000003f7597640] [c0000000009abc60] __schedule+0x320/0xaa0 > [c0000003f7597710] [c0000000009ac420] schedule+0x40/0xb0 > [c0000003f7597740] [c0000000009b09d4] schedule_timeout+0x254/0x440 > [c0000003f7597820] [c0000000009aca80] io_schedule_timeout+0x30/0x60 > [c0000003f7597850] [c0000000009ad75c] wait_for_common_io.constprop.2+0xbc/0x1e0 > [c0000003f75978d0] [c000000000509e6c] blk_execute_rq+0x4c/0x70 > [c0000003f7597920] [c000000000654abc] scsi_execute+0xfc/0x260 > [c0000003f7597990] [c000000000654f98] scsi_mode_sense+0x218/0x410 > [c0000003f7597aa0] [c00000000068ee68] sd_revalidate_disk+0x908/0x1cd0 > [c0000003f7597be0] [c000000000690434] sd_probe_async+0xb4/0x220 > [c0000003f7597c60] [c000000000110a20] async_run_entry_fn+0x70/0x170 > [c0000003f7597ca0] [c000000000103904] process_one_work+0x2b4/0x560 > [c0000003f7597d30] [c000000000103c38] worker_thread+0x88/0x5a0 > [c0000003f7597dc0] [c00000000010bfcc] kthread+0x15c/0x1a0 > [c0000003f7597e30] [c00000000000ba1c] ret_from_kernel_thread+0x5c/0xc0 Hello Michael, It is suspicious that entries like the above appear in the SysRq-w output. Every time I saw this in the past it was caused by a block driver not having called blk_end_request() or a SCSI LLD not having called .scsi_done(). Additionally, it is unlikely that the patch at the start of this thread introduced this issue. Can you have another look at the ipr driver? If a shell is available at the time this lockup occurs, it will probably be helpful to have a look at the debugfs entries under /sys/kernel/debug/block/. Thanks, Bart.
