[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40700595-8c83-1b61-ea93-ea9554bfb2db@acm.org>
Date: Mon, 15 Aug 2022 06:49:12 -0700
From: Bart Van Assche <bvanassche@....org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: "Martin K . Petersen" <martin.petersen@...cle.com>,
Jaegeuk Kim <jaegeuk@...nel.org>,
scsi <linux-scsi@...r.kernel.org>,
Ming Lei <ming.lei@...hat.com>, Hannes Reinecke <hare@...e.de>,
John Garry <john.garry@...wei.com>, ericspero@...oud.com,
jason600.groome@...il.com,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-ide@...r.kernel.org,
James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support
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.
Powered by blists - more mailing lists