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

From: Bart Van Assche
Date: Mon Aug 15 2022 - 09:49:27 EST


On 8/15/22 03:13, Geert Uytterhoeven wrote:
Showing all locks held in the system:
1 lock held by rcu_tasks_kthre/10:
#0: ffff800009575c38 (rcu_tasks.tasks_gp_mutex){+.+.}-{3:3}, at:
rcu_tasks_one_gp+0x34/0x4c8
4 locks held by kworker/0:10/104:
#0: ffff0004c0008738 ((wq_completion)events){+.+.}-{0:0}, at:
process_one_work+0x1f4/0x6a0
#1: ffff80000a90bde0
((work_completion)(&ap->scsi_rescan_task)){+.+.}-{0:0}, at:
process_one_work+0x1f4/0x6a0
#2: ffff0004c2b6bf60 (&ap->scsi_scan_mutex){+.+.}-{3:3}, at:
ata_scsi_dev_rescan+0x28/0x118
#3: ffff0004c2902368 (&dev->mutex){....}-{3:3}, at:
scsi_rescan_device+0x28/0x78
1 lock held by in:imklog/636:
#0: ffff0004c5ee86e8 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0x54/0x68
1 lock held by hd/1013:
#0: ffff0004c06388b8 (mapping.invalidate_lock#2){.+.+}-{3:3}, at:
page_cache_ra_unbounded+0x64/0x1a8

Thank you for having shared this information. I will take a closer look and see what I can derive from the above information.

I've just tried with a USB storage device on the same platform,
and it can be read fine after s2idle. So it looks like the issue
is related to SATA.

Unfortunately the above does not learn us anything new. The code modified by commit 88f1669019bd ("scsi: sd: Rework asynchronous resume support") is only called if sdev->manage_start_stop != 1. Only the SATA code, the Firewire code and the manage_start_stop sysfs attribute store method set that member variable:

$ git grep -nH 'manage_start_stop = '
drivers/ata/libata-scsi.c:1083: sdev->manage_start_stop = 1;
drivers/firewire/sbp2.c:1521: sdev->manage_start_stop = 1;
drivers/scsi/sd.c:240: sdp->manage_start_stop = v;

Would it be possible to share the output of the command below? That should reveal which ATA driver is active on the test setup.

find /sys -name proc_name | xargs grep -aH .

Thanks,

Bart.