[Bug 216413] New: [BISECT INCLUDED] scsi/sd Rework asynchronous resume support breaks S2idle and S3 on several systems

* [Bug 216413] New: [BISECT INCLUDED] scsi/sd Rework asynchronous resume support breaks S2idle and S3 on several systems
@ 2022-08-25 21:24 bugzilla-daemon
  2022-08-25 21:27 ` [Bug 216413] " bugzilla-daemon
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: bugzilla-daemon @ 2022-08-25 21:24 UTC (permalink / raw)
  To: linux-scsi

https://bugzilla.kernel.org/show_bug.cgi?id=216413

            Bug ID: 216413
           Summary: [BISECT INCLUDED] scsi/sd Rework asynchronous resume
                    support breaks S2idle and S3 on several systems
           Product: IO/Storage
           Version: 2.5
    Kernel Version: 6.0.0-rc1
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: blocking
          Priority: P1
         Component: SCSI
          Assignee: bvanassche@acm.org
          Reporter: todd.e.brandt@intel.com
                CC: bvanassche@acm.org, lenb@kernel.org,
                    linux-scsi@vger.kernel.org, martin.petersen@oracle.com
            Blocks: 178231
        Regression: No

A commit in 6.0.0-rc1 has caused S2idle and S3 (freeze & mem) to completely
hang the system on these 4 machines in our lab:

1) Clevo System76 Lemur 6
2) Lenovo Yoga 2 Pro
3) Dell Inspiron 3493
4) HP Pavillion x360

To reproduce the issue simply run kernel 6.0.0-rc1 or newer on these systems
and run "sudo sleepgraph -m freeze" or "sudo sleepgraph -m mem". The system
will hang after that.

I've bisected the problem to this specific commit:

88f1669019bd62b3009a3cebf772fbaaa21b9f38 is the first bad commit
commit 88f1669019bd62b3009a3cebf772fbaaa21b9f38
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Thu Jun 30 12:57:03 2022 -0700

    scsi: sd: Rework asynchronous resume support

    For some technologies, e.g. an ATA bus, resuming can take multiple
    seconds. Waiting for resume to finish can cause a very noticeable delay.
    Hence this commit that restores the behavior from before "scsi: core: pm:
    Rely on the device driver core for async power management" for most SCSI
    devices.

    This commit introduces a behavior change: if the START command fails, do
    not consider this as a SCSI disk resume failure.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215880
    Link: https://lore.kernel.org/r/20220630195703.10155-3-bvanassche@acm.org
    Fixes: a19a93e4c6a9 ("scsi: core: pm: Rely on the device driver core for
async power management")
    Cc: Ming Lei <ming.lei@redhat.com>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: John Garry <john.garry@huawei.com>
    Cc: ericspero@icloud.com
    Cc: jason600.groome@gmail.com
    Tested-by: jason600.groome@gmail.com
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

:040000 040000 dbd390c19cfddba2b559b06691404aee4c165384
54c7fa67e3a1605878999bdf1e39a95ca793238a M      drivers

Referenced Bugs:

https://bugzilla.kernel.org/show_bug.cgi?id=178231
[Bug 178231] Meta-bug: Linux suspend-to-mem and freeze performance optimization
-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply	[flat|nested] 10+ messages in thread