From: James Bottomley <James.Bottomley@SteelEye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Anton Blanchard <anton@samba.org>,
Dipankar Sarma <dipankar@in.ibm.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [2.6.14-rc1] sym scsi boot hang
Date: Wed, 14 Sep 2005 16:44:19 -0400 [thread overview]
Message-ID: <1126730659.4825.18.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0509141610480.8011-100000@iolanthe.rowland.org>
On Wed, 2005-09-14 at 16:19 -0400, Alan Stern wrote:
> On Wed, 14 Sep 2005, James Bottomley wrote:
> Then shouldn't you also avoid unprepping and reprepping a command that is
> deferred because the host isn't ready?
Yes ... really the only case for unprep is when we've partially released
the command (like in scsi_io_completion) where we need to tear the rest
of it down.
The rule should be that if it needs preparing, then it's in the same
state as the block layer would send it to us in (with no appendages).
For most requeues, we have all the prepared resources attached, so they
don't need tearing down and repreparing.
> And isn't it necessary to make sure that req->special is NULL when
> submitting a special request with no scsi_request, and that
Yes, but only if the command will be prepared again.
> cmd->sc_request is NULL when associating a command block to a special
> request with no scsi_request?
No, that's zeroed out when the command is allocated. It's only set in
the path that sends down a scsi_request.
James
> In short, is this patch needed?
>
> Alan Stern
>
>
>
> Index: usb-2.6/drivers/scsi/scsi_lib.c
> ===================================================================
> --- usb-2.6.orig/drivers/scsi/scsi_lib.c
> +++ usb-2.6/drivers/scsi/scsi_lib.c
> @@ -343,6 +343,7 @@ int scsi_execute(struct scsi_device *sde
> req->sense_len = 0;
> req->timeout = timeout;
> req->flags |= flags | REQ_BLOCK_PC | REQ_SPECIAL | REQ_QUIET;
> + req->special = NULL;
>
> /*
> * head injection *required* here otherwise quiesce won't work
> @@ -1072,9 +1073,6 @@ static int scsi_init_io(struct scsi_cmnd
> printk(KERN_ERR "req nr_sec %lu, cur_nr_sec %u\n", req->nr_sectors,
> req->current_nr_sectors);
>
> - /* release the command and kill it */
> - scsi_release_buffers(cmd);
> - scsi_put_command(cmd);
> return BLKPREP_KILL;
> }
>
> @@ -1205,6 +1203,7 @@ static int scsi_prep_fn(struct request_q
> goto defer;
> } else
> cmd = req->special;
> + cmd->sc_request = NULL;
>
> /* pull a tag out of the request if we have one */
> cmd->tag = req->tag;
> @@ -1250,7 +1249,7 @@ static int scsi_prep_fn(struct request_q
> ret = scsi_init_io(cmd);
> switch(ret) {
> case BLKPREP_KILL:
> - /* BLKPREP_KILL return also releases the command */
> + scsi_unprep_request(req);
> goto kill;
> case BLKPREP_DEFER:
> goto defer;
> @@ -1514,7 +1513,6 @@ static void scsi_request_fn(struct reque
> * cases (host limits or settings) should run the queue at some
> * later time.
> */
> - scsi_unprep_request(req);
> spin_lock_irq(q->queue_lock);
> blk_requeue_request(q, req);
> sdev->device_busy--;
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2005-09-14 20:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-13 12:48 [2.6.14-rc1] sym scsi boot hang Dipankar Sarma
2005-09-13 13:17 ` Anton Blanchard
2005-09-13 14:29 ` Anton Blanchard
2005-09-13 16:35 ` James Bottomley
2005-09-13 16:47 ` Anton Blanchard
2005-09-13 17:32 ` James Bottomley
2005-09-13 17:13 ` Anton Blanchard
2005-09-13 17:33 ` Dipankar Sarma
2005-09-14 8:06 ` Anton Blanchard
2005-09-14 15:49 ` Alan Stern
2005-09-14 16:52 ` Mike Christie
2005-09-14 16:53 ` Mike Christie
2005-09-14 20:35 ` James Bottomley
2005-09-14 16:57 ` James Bottomley
2005-09-14 20:19 ` Alan Stern
2005-09-14 20:44 ` James Bottomley [this message]
2005-09-14 21:33 ` Alan Stern
2005-09-15 13:56 ` James Bottomley
2005-09-15 14:13 ` Alan Stern
2005-09-15 17:52 ` Alan Stern
2005-09-16 10:28 ` Anton Blanchard
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=1126730659.4825.18.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=anton@samba.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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