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;
MIME-Version: 1.0
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>
In-Reply-To: <6f70e742-9d8a-f389-0482-0ba9696bf445@acm.org>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Thu, 21 Jul 2022 10:07:34 +0200
Message-ID: <CAMuHMdVc+ATGV-=R3uV6RyF0-mZiuKv7HpmogRBgqGVyO-MKWg@mail.gmail.com>
Subject: Re: [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support
To:     Bart Van Assche <bvanassche@acm.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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hoi Bart,

On Wed, Jul 20, 2022 at 8:04 PM Bart Van Assche <bvanassche@acm.org> wrote:
> On 7/20/22 10:44, Geert Uytterhoeven wrote:
> > On Wed, Jul 20, 2022 at 6:51 PM Bart Van Assche <bvanassche@acm.org> wrote:
> >> I'm not familiar with the SATA code but from a quick look it seems like
> >> the above code is only triggered from inside the ATA error handler
> >> (ata_do_eh() -> ata_eh_recover() -> ata_eh_revalidate_and_attach() ->
> >> schedule_work(&(ap->scsi_rescan_task) -> ata_scsi_dev_rescan()). It
> >> doesn't seem normal to me that the ATA error handler gets invoked during
> >> a resume. How about testing the following two code changes?
> >
> > Thanks for your suggestions!
> >
> >> * In sd_start_stop_device(), change "return sd_submit_start(sdkp, cmd,
> >> sizeof(cmd))" into "sd_submit_start(sdkp, cmd, sizeof(cmd))" and below
> >> that call add "flush_work(&sdkp->start_done_work)". This makes
> >> sd_start_stop_device() again synchronous. This will learn us whether the
> >> behavior change is caused by submitting the START command from another
> >> context or by not waiting until the START command has finished.
> >
> > Unfortunately this doesn't have any impact.
> >
> >> * Back out the above change, change "return sd_submit_start(sdkp, cmd,
> >> sizeof(cmd))" again into "sd_submit_start(sdkp, cmd, sizeof(cmd))" and
> >> below that statement add a call to
> >> scsi_run_queue(sdkp->device->request_queue). If this change helps it
> >
> > (that's the static scsi_run_queue() in drivers/scsi/scsi_lib.c?)
> >
> >> means that the scsi_run_queue() call is necessary to prevent reordering
> >> of the START command with other SCSI commands.
> >
> > Unfortunately this doesn't have any impact either.
>
> That's surprising. Is there anything unusual about the test setup that I
> should know, e.g. very small number of CPU cores or a very small queue
> depth of the SATA device? How about adding pr_info() statements at the
> start and end of the following functions and also before the return
> statements in these functions to determine where execution of the START
> command hangs?
> * sd_start_done().
> * sd_start_done_work().

None of these functions seem to be called at all?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds