Re: [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support

From: Hannes Reinecke
Date: Thu Jul 21 2022 - 01:40:35 EST


On 7/20/22 18:51, Bart Van Assche wrote:
On 7/20/22 00:47, Geert Uytterhoeven wrote:
With more debug options enabled, it prints:

INFO: task kworker/0:7:283 blocked for more than 120 seconds.
       Not tainted 5.19.0-rc7-salvator-x-00794-g6780eb02b605 #1287
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/0:7     state:D stack:    0 pid:  283 ppid:     2 flags:0x00000008
Workqueue: events ata_scsi_dev_rescan
Call trace:
  __switch_to+0xbc/0x124
  __schedule+0x540/0x71c
  schedule+0x58/0xa0
  io_schedule+0x18/0x34
  blk_mq_get_tag+0x138/0x244
  __blk_mq_alloc_requests+0x130/0x2f0
  blk_mq_alloc_request+0x74/0xa8
  scsi_alloc_request+0x10/0x30
  __scsi_execute+0x5c/0x18c
  scsi_vpd_inquiry+0x7c/0xdc
  scsi_get_vpd_size+0x34/0xa8
  scsi_get_vpd_buf+0x28/0xf4
  scsi_attach_vpd+0x44/0x170
  scsi_rescan_device+0x30/0x98
  ata_scsi_dev_rescan+0xc8/0xfc
  process_one_work+0x2e0/0x474
  worker_thread+0x1cc/0x270
  kthread+0xd8/0xe8
  ret_from_fork+0x10/0x20

This doesn't look like it's blocked in the R-Car SATA driver, but on
some I/O scheduling event in the block core?

I'm not familiar with the SATA code but from a quick look it seems like the above code is only triggered from inside the ATA error handler (ata_do_eh() -> ata_eh_recover() -> ata_eh_revalidate_and_attach() -> schedule_work(&(ap->scsi_rescan_task) -> ata_scsi_dev_rescan()). It doesn't seem normal to me that the ATA error handler gets invoked during a resume. How about testing the following two code changes?

Sadly, that _is_ the normal workflow. SATA EH gets invoked regularly, and is handling the device resets after resume.

Cheers,

Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman