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/.



Reply via email to