[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2cf6d96-a55a-d444-d22e-e9b3945ba43f@jmbreuer.net>
Date: Sun, 11 Jun 2023 11:05:27 +0200
From: Joe Breuer <linux-kernel@...reuer.net>
To: Bart Van Assche <bvanassche@....org>,
Bagas Sanjaya <bagasdotme@...il.com>,
Pavel Machek <pavel@....cz>,
Damien Le Moal <dlemoal@...nel.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <len.brown@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kees Cook <keescook@...omium.org>,
Tony Luck <tony.luck@...el.com>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
Thorsten Leemhuis <linux@...mhuis.info>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Phillip Potter <phil@...lpotter.co.uk>,
Joe Breuer <linux-kernel@...reuer.net>,
Linux Power Management <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Hardening <linux-hardening@...r.kernel.org>,
Linux Regressions <regressions@...ts.linux.dev>,
Linux SCSI <linux-scsi@...r.kernel.org>,
Alan Stern <stern@...land.harvard.edu>,
Dan Williams <dan.j.williams@...el.com>,
Hannes Reinecke <hare@...e.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Martin Kepplinger <martin.kepplinger@...i.sm>,
Kai-Heng Feng <kai.heng.feng@...onical.com>
Subject: Re: Fwd: Waking up from resume locks up on sr device
I'm the reporter of this issue.
I just tried this patch against 6.3.4, and it completely fixes my
suspend/resume issue.
The optical drive stays usable after resume, even suspending/resuming
during playback of CDDA content works flawlessly and playback resumes
seamlessly after system resume.
So, from my perspective: Good one!
So long,
Joe
On 10.06.23 17:03, Bart Van Assche wrote:
> On 6/10/23 06:27, Bagas Sanjaya wrote:
>> On 6/10/23 15:55, Pavel Machek wrote:
>>>>> #regzbot introduced: v5.0..v6.4-rc5
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=217530
>>>>> #regzbot title: Waking up from resume locks up on SCSI CD/DVD drive
>>>>>
>>>> The reporter had found the culprit (via bisection), so:
>>>>
>>>> #regzbot introduced: a19a93e4c6a98c
>>> Maybe cc the authors of that commit?
>>
>> Ah! I forgot to do that! Thanks anyway.
>
> Hi Damien,
>
> Why does the ATA code call scsi_rescan_device() before system resume has
> finished? Would ATA devices still work with the patch below applied?
>
> Thanks,
>
> Bart.
>
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 6a959c993dd8..be3971b7fd27 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -1629,6 +1629,20 @@ void scsi_rescan_device(struct device *dev)
> {
> struct scsi_device *sdev = to_scsi_device(dev);
>
> +#ifdef CONFIG_PM_SLEEP
> + /*
> + * The ATA subsystem may call scsi_rescan_device() before resuming has
> + * finished. If this happens, prevent a deadlock on the device_lock()
> + * call by skipping rescanning.
> + */
> + if (dev->power.is_suspended)
> + return;
> +#endif
> +
> + /*
> + * Serialize scsi_driver.rescan() calls and
> scsi_driver.gendrv.remove()
> + * calls.
> + */
> device_lock(dev);
>
> scsi_attach_vpd(sdev);
>
Powered by blists - more mailing lists