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.
