From: Mike Anderson <andmike@us.ibm.com>
To: "Jiang, Dave" <dave.jiang@intel.com>
Cc: linux-scsi@vger.kernel.org, "Boji T Kannanthanam (Kannanthanam,
Boji T)" <boji.t.kannanthanam@intel.com>
Subject: Re: possible bug in rmmod scsi controllers?
Date: Thu, 10 Jun 2004 12:53:04 -0700 [thread overview]
Message-ID: <20040610195304.GA7182@us.ibm.com> (raw)
In-Reply-To: <DB7891DD5641F14391475AFFF42568F50551A25E@azsmsx407>
Jiang, Dave [dave.jiang@intel.com] wrote:
> While playing around with scsi_debug on 2.6.7-rc3, I noticed that
> whenever I rmmod scsi_debug, the sync cache command always fails. After
> a little looking around it seems that whenever scsi_remove_host() is
> called, the host state is set to SHOST_CANCEL. If the disk is configured
> as write-back cache, then a SYNCH_CACHE command is issued. However, in
> scsi_dispatch_cmd() function in scsi.c a check is done to see if
> SHOST_CANCEL state is set and if so the command is rejected. Therefore
> the sync cache command always fails during unload. Something such as
> below fixes the problem:
>
> --- scsi.c.old 2004-06-10 10:43:02.478538016 -0700
> +++ scsi.c 2004-06-10 10:41:52.627157040 -0700
> @@ -576,7 +576,8 @@
> }
>
> spin_lock_irqsave(host->host_lock, flags);
> - if (unlikely(test_bit(SHOST_CANCEL, &host->shost_state))) {
> + if (unlikely(test_bit(SHOST_CANCEL, &host->shost_state)) &&
> + unlikely(cmd->device->sdev_state == SDEV_DEL)) {
> cmd->result = (DID_NO_CONNECT << 16);
> scsi_done(cmd);
> } else {
>
> However, this is a quick hack and I'm sure there are better ways to do
> this. There was a similar issue on 2.6.5 with the device state that was
> fixed in 2.6.6 which exposed this issue.
>
This is something we should try and fix, but the change here would allow
more command to flow to a scsi host in cases of unexpected disconnect
where we may not want them.
Currently right now with the scsi_remove_host call there is no way to
know that a host is being removed cleanly (i.e., rmmod) or that it is
being removed for a unexpected disconnect where it wishes no more IOs to
be sent.
I do not have a counter proposal at this time. If the LLDD could
differentiate these two cases we could possibly export and have the LLDD
use the scsi_forget_host function to remove child devices prior to
calling scsi_remove_host in the clean (rmmod) cases. There would need to
be more work if we wanted to address possible race issues of someone
trying to add a device at the sametime a rmmod was happening.
-andmike
--
Michael Anderson
andmike@us.ibm.com
prev parent reply other threads:[~2004-06-10 19:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-10 18:01 possible bug in rmmod scsi controllers? Jiang, Dave
2004-06-10 19:53 ` Mike Anderson [this message]
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=20040610195304.GA7182@us.ibm.com \
--to=andmike@us.ibm.com \
--cc=boji.t.kannanthanam@intel.com \
--cc=dave.jiang@intel.com \
--cc=linux-scsi@vger.kernel.org \
/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.