From: Bart Van Assche <bvanassche@acm.org>
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>
Subject: Re: [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support
Date: Thu, 21 Jul 2022 11:14:55 -0700 [thread overview]
Message-ID: <54e20a27-a10b-b77a-e950-1d3398e2e907@acm.org> (raw)
In-Reply-To: <CAMuHMdVc+ATGV-=R3uV6RyF0-mZiuKv7HpmogRBgqGVyO-MKWg@mail.gmail.com>
On 7/21/22 01:07, Geert Uytterhoeven wrote:
> On Wed, Jul 20, 2022 at 8:04 PM Bart Van Assche <bvanassche@acm.org> wrote:
>> 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?
That's weird. This means that either sd_submit_start() hangs or that the
execution of the START command never finishes. The latter is unlikely
since the SCSI error handler is assumed to abort commands that hang. It
would also be weird if sd_submit_start() would hang before the START
command is submitted since the code flow for submitting the START
command is very similar to the code flow for submitting the START
command without patch "scsi: sd: Rework asynchronous resume support"
(calling scsi_execute()).
What is also weird is that there are at least two SATA setups on which
this code works fine, including my Qemu setup.
Although it is possible to enable tracing at boot time, adding the
following parameters to the kernel command line would generate too much
logging data:
tp_printk
trace_event=block_rq_complete,block_rq_error,block_rq_insert,block_rq_issue,block_rq_merge,block_rq_remap,block_rq_requeue,scsi_dispatch_cmd_done,scsi_dispatch_cmd_start,scsi_eh_wakeup,scsi_dispatch_cmd_error,scsi_dispatch_cmd_timeout
scsi_mod.scsi_logging_level=32256
I'm not sure what the best way is to proceed since I cannot reproduce
this issue.
Bart.
next prev parent reply other threads:[~2022-07-21 18:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 19:57 [PATCH v2 0/2] Reduce ATA disk resume time Bart Van Assche
2022-06-30 19:57 ` [PATCH v2 1/2] scsi: core: Move the definition of SCSI_QUEUE_DELAY Bart Van Assche
2022-06-30 19:57 ` [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support Bart Van Assche
2022-07-19 9:26 ` Geert Uytterhoeven
2022-07-19 18:14 ` Bart Van Assche
2022-07-20 7:26 ` Geert Uytterhoeven
2022-07-20 7:47 ` Geert Uytterhoeven
2022-07-20 16:51 ` Bart Van Assche
2022-07-20 17:44 ` Geert Uytterhoeven
2022-07-20 18:04 ` Bart Van Assche
2022-07-21 8:07 ` Geert Uytterhoeven
2022-07-21 18:14 ` Bart Van Assche [this message]
2022-07-22 8:53 ` Geert Uytterhoeven
2022-07-22 17:56 ` Bart Van Assche
2022-08-12 10:48 ` Geert Uytterhoeven
2022-08-12 15:53 ` Bart Van Assche
2022-08-15 10:13 ` Geert Uytterhoeven
2022-08-15 13:49 ` Bart Van Assche
2022-08-15 18:26 ` Geert Uytterhoeven
2022-08-16 20:21 ` Bart Van Assche
2022-08-17 8:53 ` Sergey Shtylyov
2022-08-17 19:07 ` Vlastimil Babka
2022-08-17 19:28 ` Bart Van Assche
2022-08-28 11:52 ` [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support #forregzbot Thorsten Leemhuis
2022-07-21 5:40 ` [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support Hannes Reinecke
2022-07-07 21:07 ` [PATCH v2 0/2] Reduce ATA disk resume time Martin K. Petersen
2022-07-14 4:22 ` Martin K. Petersen
-- strict thread matches above, loose matches on Subject: below --
2022-06-29 23:56 Bart Van Assche
2022-06-29 23:56 ` [PATCH v2 2/2] scsi: sd: Rework asynchronous resume support Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54e20a27-a10b-b77a-e950-1d3398e2e907@acm.org \
--to=bvanassche@acm.org \
--cc=ericspero@icloud.com \
--cc=geert@linux-m68k.org \
--cc=hare@suse.de \
--cc=jaegeuk@kernel.org \
--cc=jason600.groome@gmail.com \
--cc=john.garry@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).