Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <084e7c5a-f98d-d61e-de81-83525851ecf9@acm.org>
Date:   Fri, 22 Jul 2022 10:56:09 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support
Content-Language: en-US
To:     Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     "Martin K . Petersen" <martin.petersen@oracle.com>,
        Jaegeuk Kim <jaegeuk@kernel.org>,
        scsi <linux-scsi@vger.kernel.org>,
        Ming Lei <ming.lei@redhat.com>, Hannes Reinecke <hare@suse.de>,
        John Garry <john.garry@huawei.com>, ericspero@icloud.com,
        jason600.groome@gmail.com,
        Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20220630195703.10155-1-bvanassche@acm.org>
 <20220630195703.10155-3-bvanassche@acm.org>
 <alpine.DEB.2.22.394.2207191125130.1006766@ramsan.of.borg>
 <db19ed29-e7f9-e5b0-3a6c-f2812078a07d@acm.org>
 <CAMuHMdVzsgSYtbJQnaigNax_JbxPsQfU+gHcteS-ojWbxUdMfw@mail.gmail.com>
 <CAMuHMdWtxBj8ug7AHTqentF8UD4jpO2sgoWWcQCOvEKLJtdq8A@mail.gmail.com>
 <506ca1a6-1122-5755-fc74-60f7c7bfbd0d@acm.org>
 <CAMuHMdVQ2K2v8jpsFfOMk99DG_sBB4_ioiQRroC7K_Ov1wvp9w@mail.gmail.com>
 <6f70e742-9d8a-f389-0482-0ba9696bf445@acm.org>
 <CAMuHMdVc+ATGV-=R3uV6RyF0-mZiuKv7HpmogRBgqGVyO-MKWg@mail.gmail.com>
 <54e20a27-a10b-b77a-e950-1d3398e2e907@acm.org>
 <CAMuHMdURQpAEGgv4cY7v0rqzs12v2TT=Amt26Y0OoBSW7YAoaw@mail.gmail.com>
From:   Bart Van Assche <bvanassche@acm.org>
In-Reply-To: <CAMuHMdURQpAEGgv4cY7v0rqzs12v2TT=Amt26Y0OoBSW7YAoaw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/22/22 01:53, Geert Uytterhoeven wrote:
> During s2idle, the following trace data is generated:
> 
>     kworker/u16:9-325     [000] ...2.   230.478731: block_rq_issue: 8,0
> N 0 () 0 + 0 [kworker/u16:9]
>     kworker/u16:9-325     [000] ...2.   230.478745:
> scsi_dispatch_cmd_start: host_no=0 channel=0 id=0 lun=0 data_sgl=0
> prot_sgl=0 prot_op=SCSI_PROT_NORMAL driver_tag=0 scheduler_tag=0
> cmnd=(SYNCHRONIZE_CACHE - raw=35 00 00 00 00 00 00 00 00 00)
>            <idle>-0       [007] d.h3.   230.478832:
> scsi_dispatch_cmd_done: host_no=0 channel=0 id=0 lun=0 data_sgl=0
> prot_sgl=0 prot_op=SCSI_PROT_NORMAL driver_tag=0 scheduler_tag=0
> cmnd=(SYNCHRONIZE_CACHE - raw=35 00 00 00 00 00 00 00 00 00)
> result=(driver=DRIVER_OK host=DID_OK message=COMMAND_COMPLETE
> status=SAM_STAT_GOOD)
>            <idle>-0       [000] ..s2.   230.478851: block_rq_complete:
> 8,0 N () 18446744073709551615 + 0 [0]
>     kworker/u16:9-325     [000] ...2.   230.483134: block_rq_issue: 8,0
> N 0 () 0 + 0 [kworker/u16:9]
>     kworker/u16:9-325     [000] ...2.   230.483136:
> scsi_dispatch_cmd_start: host_no=0 channel=0 id=0 lun=0 data_sgl=0
> prot_sgl=0 prot_op=SCSI_PROT_NORMAL driver_tag=0 scheduler_tag=1
> cmnd=(START_STOP - raw=1b 00 00 00 00 00)
>            <idle>-0       [007] d.h3.   230.624530:
> scsi_dispatch_cmd_done: host_no=0 channel=0 id=0 lun=0 data_sgl=0
> prot_sgl=0 prot_op=SCSI_PROT_NORMAL driver_tag=0 scheduler_tag=1
> cmnd=(START_STOP - raw=1b 00 00 00 00 00) result=(driver=DRIVER_OK
> host=DID_OK message=COMMAND_COMPLETE status=SAM_STAT_GOOD)
>            <idle>-0       [000] d.s4.   230.624634: scsi_eh_wakeup: host_no=0
>            <idle>-0       [000] ..s2.   230.624642: block_rq_complete:
> 8,0 N () 18446744073709551615 + 0 [0]
>    kworker/u16:14-1027    [007] d..3.   231.393642: scsi_eh_wakeup: host_no=0
> 
> When reading from hard drive after s2idle, no more trace data
> is generated.

I think the above commands come from the suspend sequence. '1b 00 00 00 
00 00' stops a block device. The lowest bit in byte 4 needs to be set to 
start a block device.

Something that is not yet clear is whether or not sd_submit_start() 
hangs during the resume process. How about verifying whether or not 
sd_submit_start() hangs by either issuing SysRq-t or by adding pr_info() 
statements in that function?

Thanks,

Bart.