From: James Bottomley <James.Bottomley@SteelEye.com>
To: Mike Anderson <andmike@us.ibm.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: BUG: CD driver sends command during host removal
Date: 11 Oct 2004 16:15:15 -0500 [thread overview]
Message-ID: <1097529322.2031.199.camel@mulgrave> (raw)
In-Reply-To: <20041011204050.GD8296@us.ibm.com>
On Mon, 2004-10-11 at 15:40, Mike Anderson wrote:
> > This is the remove implies cancel issue that was discussed earlier. I
> > thought the proposal was to have a remove that wouldn't automatically
> > cancel all the commands? ... although I don't think I've seen any code
> > for that case yet.
> >
>
> Clarification. James, are you indicating that there needs to be a new
> scsi mid api that performs similar function to scsi_remove_host expect
> does not cancel commands?
Sorry, by "a remove that .." I was meaning "another remove method that
..."
> If is unclear to me if a LLDD provides a slave_destroy which is called
> from scsi_remove_device during the scsi_forget_host function that we
> would hit a case where the LLDD has good IO to complete still
> outstanding when we complete scsi_forget_host and call scsi_host_cancel.
That depends what the LLD does with the slave destroy really. The API
doesn't say the LLD has to chase all I/Os down when slave destroy is
called, so we can't assume it has.
> Is there some locking / synchronization issue with our state changes and
> the scsi_prep_fn / scsi_request_fn / scsi_dispatch_cmd sequence?
In the device, no ... I still need to check the host.
James
next prev parent reply other threads:[~2004-10-11 21:15 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-11 19:20 BUG: CD driver sends command during host removal Alan Stern
2004-10-11 19:36 ` James Bottomley
2004-10-11 20:03 ` Alan Stern
2004-10-11 20:12 ` James Bottomley
2004-10-11 20:40 ` Mike Anderson
2004-10-11 21:15 ` James Bottomley [this message]
2004-10-11 23:13 ` Mike Anderson
[not found] <20040926082926.GA1944@uniball>
2004-09-27 18:18 ` Alan Stern
2004-09-27 18:51 ` Mohammed Sameer
2004-09-29 16:06 ` Luben Tuikov
2004-09-29 16:55 ` Alan Stern
2004-09-29 17:09 ` Mike Anderson
2004-09-29 18:02 ` Luben Tuikov
2004-09-29 18:09 ` James Bottomley
2004-09-29 18:58 ` Luben Tuikov
2004-09-29 19:39 ` James Bottomley
2004-09-29 19:01 ` Alan Stern
2004-09-29 19:27 ` Mike Anderson
2004-09-29 19:33 ` Luben Tuikov
2004-09-29 19:50 ` James Bottomley
2004-09-29 20:31 ` Mike Anderson
2004-09-29 20:41 ` James Bottomley
2004-09-29 21:07 ` Mike Anderson
2004-09-29 21:14 ` James Bottomley
2004-09-29 21:20 ` Luben Tuikov
2004-09-29 21:26 ` James Bottomley
2004-09-29 21:20 ` Alan Stern
2004-10-02 23:57 ` Mohammed Sameer
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=1097529322.2031.199.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=andmike@us.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.